1

If a Rust program panics, and assuming there are no panic catchers (which for a while there wasn't), surely it would be safe and fine to not run destructors and just let the OS clean up after the process. Why does Rust unwind the thread?

The only reason I can think of is for when there isn't an OS to reclaim the memory, but apart from that niche, it seems unnecessary.

Peter Hall
  • 53,120
  • 14
  • 139
  • 204
Timidger
  • 1,199
  • 11
  • 15
  • 1
    You may want destructors to save things, especially if something went wrong. – lilezek Sep 18 '17 at 20:13
  • 1
    And it's useful for debugging. The backtrace can help guide you to what has gone wrong. – Peter Hall Sep 18 '17 at 20:14
  • 2
    @lilezek: Actually... you should probably NOT rely on destructors to save things. The program could abort, crash, be killed by the OS, ... and in any of those cases the destructors will never run. In the context of program termination, destructors can only be used to implement "best effort" operations and should NOT be used to implement "mandatory" operations. If you want to be able to resume from where you were, you need to regularly "save" your progress during the normal execution (with an atomic switch, in case failure occur during the save...). – Matthieu M. Sep 18 '17 at 20:27
  • @MatthieuM. When I said save things I meant things like debug information, TCP socket states... Didn't meant to rely on destructors to save things to the disk (that might even break some already stored data). – lilezek Sep 18 '17 at 20:30
  • @lilezek: I am happy that we agree :) (I have unfortunately be on the receiving end of a "let's use the destructor to restore the state in the database" attempt, and spent days trying to undo the damage) – Matthieu M. Sep 18 '17 at 20:50
  • It has been possible to catch a panic across threads since Rust 1.0 (see [JoinHandle::join](https://doc.rust-lang.org/stable/std/thread/struct.JoinHandle.html#method.join)). – Francis Gagné Sep 19 '17 at 00:52

2 Answers2

5

There is a faulty premise in your question: it pre-supposes that the only reason to use a destructor is to clean-up resources of the current process.

This is, indeed, the most common usage, but it is not the only one.

For example, I could perfectly imagine that the destructor of a TCP connection would attempt to send a close message: the soonest the connection is closed, the soonest resources are released on the other end. Of course, it's only a best effort (in case of abort/crash the destructor is never run), but it can still be worthwhile.

Matthieu M.
  • 287,565
  • 48
  • 449
  • 722
2

If a Rust program panics [...] just let the OS clean up after the process.

When a panic occurs in a thread, the entire process does not need to exit. In these cases, it is good that the destructor runs.

In other cases, a Drop implementation is used to perform a "rollback" of some critical section of code.

assuming there are no panic catchers (which for a while there wasn't)

But now there are, so I'm unclear why you bring it up.

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366