Stack Traces Are Underrated
karl.berlin
Stack Traces Are Underrated
1–10 of 58 posts
Re: Stack Traces Are Underrated
#2Don't worry. Just wait until you start doing async stuff, especially with React.
You'll be dreaming of good old times of linear stacktraces.
Re: Stack Traces Are Underrated
#3> But Rust has a better workaround to create stack traces: the backtrace module, which allows capturing stack traces that you can then add to the errors you return. The main problem with this approach is that you still have to add the stack trace to each error and also trust library authors to do so.
That's technically true, but the situation is not as dire. Many errors do not need stack traces. That so few carry a backtrace in Rust is mostly a result of the functionality still not being stable [1].
The I think bigger issue is that people largely have given up on stack traces I think, in parts because of async programming. There are more and more programming patterns and libraries where back traces are completely useless. For instance in JavaScript I keep working with dependencies that just come minified or transpiled straight out of npm. In theory node has async stack traces now, but I have yet to see this work through `setTimeout` and friends. It's very common to lose parts of the stack.
Because there are now so many situations where stack traces are unreliable, more and more programmers seemingly do lose trust in them and don't see the value they once provided.
I also see it in parts at Sentry where a shocking number of customers are completely willing to work with just minified stack traces and not set up source maps to make them readable.
Re: Stack Traces Are Underrated
#4I have been an avid proponent of the way errors are managed in Rust and Go for a long time. However, this article raises a very good point. Before i started developing in Rust and Go, i did Java and python for several years. And damn, do i miss those stacktraces every now and then when something bad happens that isn't properly handled by the code.
Still, i do think returning the error as a return value is better than having a completely separate flow when dealing with exceptions. I like that it forces me to properly deal with an error and not just ignore it and think something like "meh, i'll get to this later". Because i will never "get to it later".
Re: Stack Traces Are Underrated
#5Way before I consistently used step debuggers and would just "print-debug" println("why are you here?") or "raise-debug" raise new Error("huh?"), I tinkered with a step debugger, but found it too complex and hard. But I remember that it also allowed me to move backwards in the stack.
It allowed me to go some frames back - lines up, up in the stack. I don't recall the name of this debugger, nor what language it was. But I've never since seen this, yet very often wished I had it (for rust, javascript, python, mostly).
Did I misremember? Can such a thing exist? Does it exist?
Re: Stack Traces Are Underrated
#6Way before I consistently used step debuggers and would just "print-debug" println("why are you here?") or "raise-debug" raise new Error("huh?"), I tinkered with a step debugger, but found it too complex and hard. But I remember that it also allowed me to move backwards in the stack. It allowed me to go some frames back - lines up, up in the stack. I don't recall the name of this debugger, nor what language it was. B…
Time travel debugging is the category, but I can’t help you much more than that with the tool names.
Re: Stack Traces Are Underrated
#7Don't worry. Just wait until you start doing async stuff, especially with React. You'll be dreaming of good old times of linear stacktraces.
Node 16 was supposed to make this situation much better but you sure could have fooled me. Is there less salt in my wounds? Sure.
Re: Stack Traces Are Underrated
#8While you're debugging using AI (specifically, ChatGPT o1), you can benefit from copying stack traces. It debugs better than if you just describe what's wrong.
Another tip: I have found that it is helpful to ask AI to "deeply analyze" (use those words) and think about the problem without providing a solution (say "don't reply with any code"). If you don't do that, it will take its first guess and then eagerly start outputing code that is still wrong and doesn't really identify or fix the issue. When you ask it to deeply analyze what's wrong and not reply with any code, it frequently finds the true underling problem, and then you can ask for how to solve it in the next step.
Re: Stack Traces Are Underrated
#9They are useful sure, and I print a stacktrace on any type of error/exception, but often breaking into the debugger is even more useful and faster as you can see local variables, program state, and what other threads happen to be doing.
Re: Stack Traces Are Underrated
#10Great point. I've found it's very often possible to understand and fix problems "one shot" from stack traces alone — and we're talking production builds here... So I wouldn't turn them off, (an idea mentioned in the article), unless profiling shows that they are one of the last things preventing the code from reaching the target performance.