RUST_BACKTRACE in production use

In the error-chain crate evaluation, @brson wrote:

Why is it expected that RUST_BACKTRACE isn’t enabled in normal operation? I would expect it to be enabled in most production uses. What are the cons of doing so?

I always enable them personally. There are cases where the libbacktrace internals run into pathologically slow edge cases where you may want the ability to turn them off, though. Example

A few of my projects have env::set_var("RUST_BACKTRACE", "1") at entry points specifically to have backtraces in output always. Often errors aren’t easily reproducible so the backtrace is very nice. I’ve thought about suggesting that the compiler could have an option to unconditionally enable backtraces for programs at compile time.

Here is something I wrote when error chain was announced. Here’s my rationale for not wanting to encourage backtraces in production:

I can certainly see how a backtrace would be interesting during development work while recoverable error cases are not yet handled, but I don’t think “generate a backtrace by default whenever we stray from the happy path” is likely to be a helpful mindset for making a robust final product.

1 Like

Is the idea that people would try harder to not write bugs if the diagnostic experience is worse?


@BatmanAoD I think most people would probably want to run with RUST_BACKTRACE enabled for panics but where error construction doesn’t exeecute any costly logic to collect and store backtraces. In particular, we expect panics should (approximately) never happen so it makes sense for them to be heavyweight. However error results are much more common.

I hadn’t thought about the fact that RUST_BACKTRACE controls panic backtraces. If you click through the link I provided to my original comments, you’ll see that we’re in complete agreement: my whole argument is about the division between types of errors.

@brson helped clarify this idea:

In short, I think backtraces are probably always valuable during development, but, in theory, backtraces for propagated failure codes that are explicitly included in function signatures should never be useful in production. In fact, since the compiler issues a warning when a Result error is not checked, it should be nearly trivial to statically ensure that error-chain’s backtraces won’t ever be needed.

Sorry to be unclear–I see how my quote out of context could give that impression. Hopefully my thoughts above should help clarify.

Never be needed in production, I assume? I certainly regularly find myself wanting a backtrace for where some Err was created during development.

…well, yes, I did mean never needed in production. But even in development I only really understand the need for backtraces for Err when the Err case is unhandled and ultimately propagates to the top-level main, terminating the application–i.e. when it behaves like a panic.

Really, I think that there needs to be a setting in which panic includes backtraces (and I would want this turned on even in production) but err-chain does not.


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.