我正在 Rust 中创建一个终端文本编辑器。编辑器将终端置于原始模式,禁用字符回显等,退出时恢复原有终端功能。
但是,编辑器有一些错误,并且由于无符号变量下溢等问题,不时意外崩溃。发生这种情况时,将终端还原到其原始状态的清理代码永远不会运行。
我想运行的清理功能如下:
fn restore_orig_mode(editor_config: &EditorConfig) -> io::Result<()> {
termios::tcsetattr(STDIN, termios::TCSAFLUSH, &editor_config.orig_termios)
}
在最新的稳定版 Rust 中,@for1096 的答案是最好的。在您的情况下,应用它可能非常简单,因为您的清理不需要使用与应用程序代码共享的状态:
use std::panic::catch_unwind;
fn run_editor(){
panic!("Error!");
println!("Running!");
}
fn clean_up(){
println!("Cleaning up!");
}
fn main(){
match catch_unwind(|| run_editor()) {
Ok(_) => println!("Exited successfully"),
Err(_) => clean_up()
}
}
如果清理需要访问与应用程序的共享状态,则需要一些额外的机制来说服编译器它是安全的。例如,如果您的应用程序如下所示:
// The shared state of your application
struct Editor { /* ... */ }
impl Editor {
fn run(&mut self){
println!("running!");
// panic!("Error!");
}
fn clean_up(&mut self){
println!("cleaning up!");
}
fn new() -> Editor {
Editor { }
}
}
然后,为了调用clean_up
,您必须管理对数据的访问,如下所示:
use std::panic::catch_unwind;
use std::sync::{Arc, Mutex};
fn main() {
let editor = Arc::new(Mutex::new(Editor::new()));
match catch_unwind(|| editor.lock().unwrap().run()) {
Ok(_) => println!("Exited successfully"),
Err(_) => {
println!("Application panicked.");
let mut editor = match editor.lock() {
Ok(guard) => guard,
Err(poisoned) => poisoned.into_inner(),
};
editor.clean_up();
}
}
}
在 Rust 1.9 之前,您只能处理子线程中发生的恐慌。除了您需要克隆Arc
之外,这没有太大区别,因为原始move
d 到线程闭包中。
use std::thread;
use std::sync::{Arc, Mutex};
fn main() {
let editor = Arc::new(Mutex::new(Editor::new()));
// clone before the original is moved into the thread closure
let editor_recovery = editor.clone();
let child = thread::spawn(move || {
editor.lock().unwrap().run();
});
match child.join() {
Ok(_) => println!("Exited successfully"),
Err(_) => {
println!("Application panicked.");
let mut editor = match editor_recovery.lock() {
Ok(guard) => guard,
Err(poisoned) => poisoned.into_inner(),
};
editor.clean_up();
}
}
}
试试catch_unwind
.我没有使用过它,所以我不能保证它有效。
在Unix应用程序中和使用其他语言(如C(中解决此问题的常见方法是fork()
并让您的父母等待孩子。在孩子退出错误时,清理。
如果清理很重要,这确实是唯一可靠的清理方法。例如,您的程序可能会被 Linux OOM 杀死。它永远无法运行特定于语言的恐慌、异常、at_exit或类似的东西,因为操作系统只是破坏了它。
通过让一个单独的进程监视它,该进程可以处理文件或共享内存的任何特殊清理。
此解决方案实际上不需要使用 fork()
.父级可以是 shell 脚本或单独的可执行文件。