Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stack Traces Are Underrated

karl.berlin

Post reply on HN
Print view View original

21–30 of 58 posts

Re: Stack Traces Are Underrated

#21

Post by windward »

>Are they just not used to having them so that they don't miss them?

The languages that I work in that don't print useful traces are typically strongishly-typed system languages. So I miss them - sometimes having to step through offending lines of code in a debugger - but I also completely avoid a whole class of bugs that are responsible for most of my stack traces in Python.

TFA's example isn't one of these, but is a function that would have a return code checked and logged if erroneous. This class of bug also can't be inlined and makes an easy breakpoint-ee.

Re: Stack Traces Are Underrated

#22

Post by miohtama »

rollulus wrote: post #17

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

Stack traces are a feature for developers to locate and fix bugs easily, and should not be a feature for end users.

Re: Stack Traces Are Underrated

#23

Post by miohtama »

cyberax wrote: post #2

Don't worry. Just wait until you start doing async stuff, especially with React. You'll be dreaming of good old times of linear stacktraces.

Windows 95 introduces threads as a revolution for developer productivity, and you had no longer write async Windows event loops which were hard to debug. Linear stack traces are one of the main selling point, among others.

Re: Stack Traces Are Underrated

#24

Post by bob1029 »

Stack traces are your #1 ally when supporting someone else's legacy production pile.

Once you get comfortable with how they work and what information they contain, you can hit the ground running anywhere. Stack traces will teach you about the product architecture faster than anyone on the team can.

As you embrace them, you take the little bit of extra time to make sure they go well. For example, re-throwing exceptions correctly, properly awaiting results, etc. Very minor details that make all the difference.

A broader outcome of this enlightenment is preference for monolithic products. Stack traces fare poorly across web service and API boundaries. If you've only ever worked with microservice architectures, the notion of a stack trace may seem distracting.

Re: Stack Traces Are Underrated

#25

Post by piva00 »

TinkersW wrote: post #20
piva00 wrote: post #12

Earlier quoted context omitted.

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.

Remote debugging is a thing but not very practical when you have hundreds of instances of your application running across dozens/hundreds of servers.

For smaller scale apps it's a godsend but I haven't worked in that environment in more than a decade so remote debugging is essentially useless in my work.

Re: Stack Traces Are Underrated

#26

Post by jeroenhd »

reseasonable wrote: post #13
hinkley wrote: post #6

Earlier quoted context omitted.

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.

I distinctly remember C# having a similar capability many years ago too.

Of course, this was in the hyper expensive Visual Studio Enterprise IDE, not something like VS Code, which high school me totally paid 4 grand for and didn't pirate at all.

These days, features like these are making it to free or cheap tools.

Re: Stack Traces Are Underrated

#27

Post by the_mitsuhiko »

johncolanduoni wrote: post #19
the_mitsuhiko wrote: post #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 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.

Only until you spawn it into an executor :(

Re: Stack Traces Are Underrated

#28

Post by the_mitsuhiko »

reseasonable wrote: post #18
the_mitsuhiko wrote: post #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 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…

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

React is a good example of a library that is a transpiled mess when installed from npm. Sadly not the only one, there are many more popular libraries that look like this.

Re: Stack Traces Are Underrated

#30

Post by albertzeyer »

Stack traces are very valuable. Sometimes it can even help to attach them to some object creation, when you later wonder why/how/where this object was created. E.g. in TensorFlow, every single Tensor had a traceback attached to it, so when there was any error later on, it would show you where it was created. This is maybe less needed now with eager mode, but you might have other similar situations.

One problem with stack traces is maybe that they can be too verbose. E.g. if you print them for any warning you print to log (or stdout). Sometimes they will be extremely helpful for debugging some problem, but in many cases, you maybe don't need them (you know why you get the warning and/or you don't care about it).

You could also add more information to the stack trace such as local variables. That can be even more helpful for debugging then, but again adds more verbosity.

For example, we often use this to add information about relevant local variables: https://github.com/albertz/py_better_exchook

One solution to the problem with verbosity is when you have foldable text output. Then the stack trace is folded away (not shown in all details) and you can unfold it to see the details. See the DomTerm demo here: https://github.com/albertz/py_better_exchook#domterm

Some more on text folding:

https://github.com/PerBothner/DomTerm/issues/54

https://gitlab.com/gnachman/iterm2/-/issues/4950

https://github.com/xtermjs/xterm.js/issues/1875

https://gitlab.freedesktop.org/terminal-wg/specifications/-/...

https://github.com/vercel/hyper/issues/1093

Post reply on HN