我在Rust中创建了一个终端文本编辑器。编辑器将终端置于原始模式,禁用字符回显等,然后在退出时恢复原始终端功能。
然而,由于无符号变量下溢等问题,编辑器出现了一些错误,并且一次又一次地意外崩溃。发生这种情况时,将终端恢复到原始状态的清理代码永远不会运行。
我想要运行的清理功能如下:
fn restore_orig_mode(editor_config: &EditorConfig) -> io::Result<()> {
termios::tcsetattr(STDIN, termios::TCSAFLUSH, &editor_config.orig_termios)
}
答案 0 :(得分:4)
在最新的稳定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
进入线程闭包。
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();
}
}
}
答案 1 :(得分:0)
试试catch_unwind
。我没有用它,所以我不能保证它有效。
答案 2 :(得分:0)
在Unix应用程序中使用其他语言(例如C)的常见解决方案是fork()
并让您的父母等待孩子。如果孩子退出错误,请清理。
如果清理很重要,这实际上是唯一可靠的清理方法。例如,您的程序可能会被Linux OOM kill杀死。它将永远无法运行语言特定的恐慌,异常,at_exit或类似的东西,因为操作系统只是破坏它。
通过让一个单独的进程观察它,该进程可以处理任何特殊的文件清理或共享内存。
此解决方案实际上并不需要使用fork()
。父可以是shell脚本或单独的可执行文件。