I am a big fan of Lisp SBCL stack traces; even in complex projects I never saw before, I'm almost always able to read, interpret and fix the issue just from that.
Stack Traces Are Underrated
11–20 of 58 posts
Re: Stack Traces Are Underrated
#12They 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.
Hard to break into the debugger for a production application running on hundreds of servers.
Re: Stack Traces Are Underrated
#13Way 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.
VB6 had it, and iirc you could even edit the code after stepping back to step forward on a different path. While trying to confirm that with a quick google I see that visual studio added stepping back in 2017. Though not sure it supports editing inline.
Re: Stack Traces Are Underrated
#14Way 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…
In Java-world it's very common.
Re: Stack Traces Are Underrated
#15In C# the quasi mandatory async/await for everything has many downsides, particularly for debugging. It breaks all stack traces. It also makes it impossible to pause the code.
Re: Stack Traces Are Underrated
#16In C# the quasi mandatory async/await for everything has many downsides, particularly for debugging. It breaks all stack traces. It also makes it impossible to pause the code.
Ha?
Can you give an example? I've seen lots of perfectly good stack traces in async code - no problems at all.
Pausing code also works, at least using vs or rider.
Re: Stack Traces Are Underrated
#17Depends on the audience. As a user I'd rather see "can't load data: failed to parse header: wrong number of elements" than a stack trace with WrongNumbersOfElementsException at the tail.
Re: Stack Traces Are Underrated
#18> 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 b…
Not sure about node (and I don’t recall it ever being a problem), but chrome supports stack traces through setTimeout just fine.
I’m not sure there are many reputable modules on npm that minify without source maps, and if people aren’t using them I’d consider them to be making a poor technical choice, one that I would correct before contributing to the project.
Diffing two lengthy stack traces to find a divergence is perhaps the fastest way to debug a slew of bug types. Let alone just the ability to instantly click into a file/line even from console prints as you follow the execution path.
And my favorite part is being able to ignore / hide external modules and specific files in chrome’s debugger which allows for stepping through only your code, and evaluating much shorter traces. Something java needed decades ago.
When I do use print debugging I always use console.error to include the expandable stack trace as needed, I can’t imagine how slow it would be to not have that always, and have to resort to stepping and breakpoints to get around.
Re: Stack Traces Are Underrated
#19> 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 b…
One nice side effect of how Rust’s Futures work is that in many cases “normal” stack traces actually reflect the async/await flow accurately. You should see a series of “poll” methods called on each future in the async call chain.
Re: Stack Traces Are Underrated
#20They 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.
Hard to break into the debugger for a production application running on hundreds of servers.
Perhaps, but remote debugging is a thing, though triggering an auto break into debugger would be more complex.