First, thanks @IanPartridge for starting this discussion. I think we all agree that the current situation is not optimal and we are very eager to do something about it.
We have been collecting some information about how other languages with a similar scope as Swift handle this today. The most prominent ones are probably C++, Go and Rust. They all have support for retrieving backtraces, with varying degrees of options and manual work required. Go and Rust both have built-in support for printing backtraces. Go always does it with no configuration required, while Rust only prints the backtrace when the environment variable RUST_BACKTRACE is set to “1”. Rust also by default strips debug symbols from release builds (just like Swift), so building with “-g” is required in release mode. Go does not differentiate between debug and release builds and always includes debug symbols. Both languages also allow users to catch and recover from panics, in which case a backtrace must be printed manually by the user, which in Go can be done with
PrintStack() , found in the
runtime/debug package and in Rust it can be retrieved using the
backtrace crate (https://crates.io/crates/backtrace). C++ does not by default print a backtrace on crashes, but they can be manually retrieved using
backtrace() and then demangeled with
cxa_demangle() , or more comfortably by using the boost stacktrace module (https://github.com/boostorg/stacktrace).
So there is quite a bit of prior art here, that could be used as inspiration. In Swift today there's no built-in way to trap panics, but signal handlers can be used instead (like Ian already does in his library). I think a good start would be to check our options (e.g.
libunwind ) and see how well each of those work on the platforms we want to support. Also how much control do we want to give the user. Is it sufficient to just install a pre-defined hook and print the backtrace, or should users be able to install their own hooks and be able to retrieve the backtrace as a proper data structure (like in Rust's backtrace crate).
We think this would be a great candidate for a SSWG hosted project and would love to join your effort in making this real, as this would dramatically improve the overall experience of developing server-side Swift code.
Looking forward to discussing this more.