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.

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

Proxied content from gemini://yujiri.xyz/software/library-stack-traces.gmi

Gemini request details:

Original URL
Status code
text/gemini; lang=en
Proxied by

Be advised that no attempt was made to verify the remote SSL certificate.

What is Gemini?