4 ms·
It has `catch_unwind` [1], but that still retains the panicking runtime, so not sufficient in the context of the post. [1] https://doc.rust-lang.org/std/panic/
by dccsillag 2y ago
It has `catch_unwind` [1], but that still retains the panicking runtime, so not sufficient in the context of the post.
[1] https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/fn.catch_unwind.html
- gpm 2y agoIt's also not guaranteed to catch every panic - sometimes (notably if a destructor panics during unwinding) a panic can turn into a process-abort.
- LegionMammal978 2y agoTo add to that, Rust code is generally not written to be 'exception-safe' when panics occur: if a third-party function causes a panic, or if your own code panics from within a callback, then memory may be leaked, and objects in use may end up in an incorrect or unusable state. You really want to avoid sharing mutable objects across a catch_unwind() boundary, and also avoid using it on a regular basis. Aside from memory leaks, panicking runs the thread's panic hook, which by default prints a stacktrace. You can override the panic hook to be a no-op, but then you won't see anything for actual panics.