There was a similar thread here but I don’t want to necrobump.
Currently, we only have
std::process::exit(). It does exactly what its name does - exits. Without cleaning up anything. In particular, without calling destructors.
In some programming cases, we may find out that we have no more work to do and just need to exit. This may happen very deep in the call tree. The currently possible solutions, which came up in a discussion on IRC, are:
std::process::exit. This, as said before, invokes no destructors and may be a source of bugs. There’s no use duplicating code and writing custom cleanup functions (which do exactly the same as the Drop trait) and at some time forget that we have this buffered logger in completely separate part of code we forgot about, or a created temporary file we were to delete, or some Unix socket we wanted to delete, …
- Propagate the “end of program” condition. Here, if we use
Result- we create nonsense in our code, using the
Errvariant for cases where no error has occurred. If use something else, e.g. an
enum, we can’t simply use the
?macro, so we clutter the code at any exit point. Of course, we can write our own, make it a crate, … And what if we were using
Command::newto launch a command and just want to exit with the child’s exit code…
std::process::exitat the last line…?
But remember, we were just to exit the program. And this is not an error, no exception - just time to finish our work.
I perfectly know that stack unwinding is very costly in Rust - but the program is going to terminate anyway in a while, so I don’t find it a big problem in this case. It is the whole power of destructors that they get invoked without the programmer having not to forget about them.
Is this a design decision not to support
exit with unwinding or is it just something that is planned for future releases?