Including library code in stack traces
One thing that bothers me a lot in stack traces is when they include library code, even standard library, and treat it the same as my code. The least helpful stack trace is one that clutters the actually useful information with frames from the bowels of a dependency I have nothing to do with and that certainly aren't responsible for the problem.
I've found it particularly bad with Python web frameworks. Who wants to debug this:
There are two frames here that are my code, and neither of them is the problem.
If you're interested, the problem was that my route's header paramaters were flagged with type annotations: `x_forwarded_for: Header('')` when it should've been `x_forwarded_for = Header('')`.
In Go, Rust and Julia, stack traces include *even the standard library* by default. Python usually doesn't do that.
I understand that in theory this information *could* be useful (though it's never been to me), but there are better ways to provide information that's only occasionally useful.
- Visually distinguish the library frames. If stderr is a terminal, color them differently. Otherwise, set them apart with whitespace and/or a clear separator. Still makes the output large, but much more readable.
- Use a compile-time or interpreter flag. Improves readability more, but may run the risk of introducing bugs that depend on such settings.
A possible objection: how can the language distinguish library code from user code? I think it's fairly straightforward: if it's imported from library search folders, it's library code. If it's imported from places that wouldn't be searched if not for the location of the code being run, it's user code. The person writing the user code is almost never interested in stack frames from libraries.
subscribe via RSS