Re:Getting Past C
by steveklabnik on Tuesday January 03, 2017 @08:45PM
(#13315020)
A panic _may_ call destructors, but it cannot be relied upon. For example, aborting is a perfectly reasonable panic implementation, and your destructors won't get called. If you have unwinding panics, they will call destructors though.
Re:Getting Past C
by Manishearth on Tuesday January 03, 2017 @09:08PM
(#13315105)
I mean, in case of an abort the kernel generally cleans things up for you :) Not all things, but most things.
More exotic panics (like an infinite loop panic on a microcontroller) would not call destructors though.
Most panic impls will either unwind (which will call destructors) or abort/exit, so this is usually not a problem.
Re:Getting Past C
by steveklabnik on Tuesday January 03, 2017 @09:10PM
(#13315117)
Memory will get cleaned up, but your destructors aren't gonna get called.
Re:Getting Past C
by jstewartmobile on Tuesday January 03, 2017 @09:43PM
(#13315254)
I'm speaking mostly in terms of recoverable errors where it jumps to a logging section, carries on, but leaks memory.
Re:Getting Past C
by Manishearth on Tuesday January 03, 2017 @11:23PM
(#13315667)
You'd generally use Result<T> for recoverable errors (which won't have any destructor issues), but in some cases you might put a panic::recover at the event loop level (never seen this being done before, but I can imagine it happening) which catches the panic (only calling destructors up to the catch point -- this is done by the unwind mechanism) and moving on to the next event in the loop.
2) I can't remember if a panic in Rust calls destructors, which would clean up that memory. Can someone answer that please?
3) is only relevant in FFI scenarios in Rust, and everywhere else is irrelevant because Rust does not require the use of such footguns for basic string manipulation.