There must be an obvious downside to always having backtraces enabled since it's not the default, but after a few minutes of googling I'm surprised that I can't find an explanation. Could someone please explain?
I have no idea really. Except to guess that most of the time it is not needed. I can usually guess immediately where my problem is because I have just written it. It saves masses of junk dumped on the terminal when not required.
Backtrace is only useful during debugging. I don't want the
exa or whatever cli utils to print dozen lines of backtraces on some weird case.
Ok I guess it depends on your use case.
For me, if a production application throws an error, it's likely to be difficult to reproduce and I want to see as much information as possible.
I agree with everyone here. When I would toggle for debugging purposes I noticed that the default output was most often spot-on in pointing out my code that was causing the error. This is not my experience in other languages I use where without the backtrack who knows what’s going on.
Capturing a backtrace can be expensive (depending on the platform), so running with
RUST_BACKTRACE will hurt performance of programs that panic frequently.
However, I think that the majority of Rust programs do not recover from panics frequently (or at all), so I agree that having backtraces enabled would be a more sensible default. The few programs that need to worry about the performance impact could easily opt out of backtrace logging.
This Reddit comment notes that, at the time backtraces were implemented, Rust still had a more Erlang-like design where panicking a lightweight task was supposed to be a cheap and common type of error handling. (This changed when the task runtime was removed in late 2014.)
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.