Experts catching panics wrong?

It's unstable, unfortunately:

https://doc.rust-lang.org/nightly/unstable-book/language-features/cfg-panic.html

Thanks, I will look. Unstable is good enough for testing.

Thinks to self before looking at link ...
"so then because cfg_panic is 'unstable' I probably need to set a cfg test to check if cfg_panic is enabled before I use the cfg_panic config test in my code."

Is this a fair summary:

(1) Writing unsafe code that allows for panics is difficult ( or at least it is easy to overlook that a panic might leave memory in an unsafe state ), and experts have made mistakes in this area. Panic safety is one of three mistakes that the Rudra project found lead to memory bugs in unsafe Rust.
( Static Analyzer Rudra Found over 200 Memory Safety Issues in Rust Crates )

(2) Catching panics is not difficult, although you need to make sure any state is restored to correct values, and avoid using panic in any drops that could occur during unwinding. Typically this will mean discarding any changes that have been made, making sure any cached data is correct. However this needs to be done with conventional Result-based error handling as well, if program execution is not to be aborted.

I don't really see where this is going? The whole point of Result-based error handling is that you don't need to perform additional manual cleanup, since Result is just a value, ? is equivalent with a regular return, and RAII solves the rest.

If an error occurs, then typically you will want to undo any changes that were made prior to the error ( or perhaps more typically stop them becoming permanent ). This needs to be done regardless of the error-handling scheme involved ( as far as I can see ). Of course, it all depends on the general context, what is going on. I am thinking of a database transaction type scenario, where some changes to data are prepared ( but not committed to permanent storage), an error occurs, and the transaction is therefore "rolled back".

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.