Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.


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.


Memory will get cleaned up, but your destructors aren't gonna get called.


I'm speaking mostly in terms of recoverable errors where it jumps to a logging section, carries on, but leaks memory.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: