4 ms·
A properly-designed Rust API will not allow code without error handling to compile, so 1) should be much less relevant in Rust. 2) I can't remember if a panic
by moosingin3space 10y ago
A properly-designed Rust API will not allow code without error handling to compile, so 1) should be much less relevant in Rust.
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.
- steveklabnik 10y agoA 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.
- Manishearth 10y agoI 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.
- steveklabnik 10y agoMemory will get cleaned up, but your destructors aren't gonna get called.
- jstewartmobile 10y agoI'm speaking mostly in terms of recoverable errors where it jumps to a logging section, carries on, but leaks memory.
- Manishearth 10y agoYou'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.