RUST_BACKTRACE in production use

[briansmith]

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

@brson

Also, the current docs say that backtraces are only collected if RUST_BACKTRACE is enabled, so there should be no significant performance hit under normal operation.

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?

[sfackler]

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 https://github.com/rust-lang/rust/issues/42295

[Mark_Simulacrum]

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.

[BatmanAoD]

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.

[sfackler]

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

[briansmith]

@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.

[BatmanAoD]

@briansmith

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.

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.

@BatmanAoD

...backtraces are only of interest for debugging fatal errors, which is very separate from programmatic handling of recoverable error conditions.

@brson helped clarify this idea:

@BatmanAoD

@brson

backtraces are useful for debugging unexpected errors.

Oh, yes, absolutely. (That's actually a much better statement than my "only of interest for debugging fatal errors"--I think what I'm really trying to get at is unexpect errors should be fatal if possible.) But how can an error be unexpected if it's part of the signature of a method?

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.

@sfackler

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

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

[RalfJung]

@BatmanAoD

it should be nearly trivial to statically ensure that error-chain’s backtraces won’t ever be needed.

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

[BatmanAoD]

…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.