# \[stdlib\] Cleanup callback for fatal Swift errors **URL:** \ **Category:** Pitches\ **Created:** [July 15, 2019, 12:12pm UTC](https://forums.swift.org/t/stdlib-cleanup-callback-for-fatal-swift-errors/26977 "2019-07-15T12:12:33Z")\ **Posts on this page:** 1\ **Showing post:** 6
**Author:** ![Joe\_Groff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_groff/32/1929_2.png) [@Joe\_Groff](https://forums.swift.org/u/Joe_Groff)\ **Post date:** [July 17, 2019, 5:02pm UTC](https://forums.swift.org/t/stdlib-cleanup-callback-for-fatal-swift-errors/26977/6 "2019-07-17T17:02:04Z")
> [@Michael\_Ilseman](#): > > CC @ktoso, who has also been looking into adapting something similar to Rust’s approach for Swift. > > This kind of functionality is important for Swift to add, but it will likely require careful design and iteration to make it sound with Swift’s semantics. For example, you may want to ensure defer blocks and deinits are executed (i.e. unwinding). If I understand @kattrali's proposal correctly, it seems like `onFatalError` would be something that runs immediately before program termination, since this API doesn't provide any indication of where to continue from or whether the error is considered to be handled. An API like this still seems useful to be able to log backtraces, but to me, the safest thing to do would be to crash without trying to unwind anything. If we introduced an interface that also allowed the program to continue executing, like what @ktoso is talking about with catching soft faults, I think leaving the crashed subprogram in a hung state, without unwinding it, might be a good incremental step toward improving the robustness of Swift programs. While not ideal, that could still let the supervisor part of your program finish servicing other requests if one crashes, for instance. --- _[View the full topic](https://forums.swift.org/t/stdlib-cleanup-callback-for-fatal-swift-errors/26977)._