6 ms·

Stack Traces Are Underrated

96 points by zoidb 2y ago

cyberax 2y ago
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.
- hinkley 2y ago
  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.
- miohtama 2y ago
  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.
Chilinot 2y ago
I 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".
- karl42 2y ago
  You could combine both by adding a stack frame each time the error is returned one level up. This could be done explicitly (cumbersome and not everyone will do it) or automatically by the language (weird magic, but useful).
the_mitsuhiko 2y ago
> 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. [1]: https://github.com/rust-lang/rust/issues/99301 https://github.com/rust-lang/rust/issues/99301
- reseasonable 2y ago
  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.
berkes 2y ago
Way 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?
- hinkley 2y ago
  Time travel debugging is the category, but I can’t help you much more than that with the tool names.
  - reseasonable 2y ago
    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.
    - jeroenhd 2y ago
      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.
  - iggldiggl 2y ago
    Time-travel debugging is something different – time-travel debugging means you can actually step backwards through the execution to try and see how you ended up with the bug. Merely being able to inspect the state of (local) variables further up the stack frame is a much more limited proposition, even if it can still be useful. > yet very often wished I had it (for […] javascript […] mostly) Both Firefox's and Chrome/Edge's devtools allow you to do that, don't they? Click on an entry in the stack frame and it takes to the corresponding code line and shows you the state of the variables relevant at that point.
logicallee 2y ago
While 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.
TinkersW 2y ago
They 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.
- piva00 2y ago
  Hard to break into the debugger for a production application running on hundreds of servers.
  - TinkersW 2y ago
    Perhaps, but remote debugging is a thing, though triggering an auto break into debugger would be more complex.
    - piva00 2y ago
      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.
  - Cthulhu_ 2y ago
    One can argue whether stack traces should be enabled for production (at least on all servers) given they're relatively expensive to create. Which isn't a problem if they're exceptional, but in a lot of cases they aren't.
    - xmcqdpt2 2y ago
      They aren’t equally expensive everywhere. They are cheap on the JVM.
montebicyclelo 2y ago
Great 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.
anonzzzies 2y ago
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.
- rootnod3 2y ago
  Oh yes. I haven't found any equivalent yet.
cm2187 2y ago
In 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.
- HdS84 2y ago
  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.
rollulus 2y ago
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.
- miohtama 2y ago
  Stack traces are a feature for developers to locate and fix bugs easily, and should not be a feature for end users.
windward 2y ago
>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.
bob1029 2y ago
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.
- pjc50 2y ago
  > 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. Yes. People forget that the original concept of microservices, the AWS "everything must have an API", was to put in an accountability boundary across teams. Either the API behaves per its contract or it does not, you're neither expected nor really allowed to cross that boundary into the API to find out why it's doing that. In an environment which is correctly doing "each microservice is a different small team", that helps. In an environment which is doing "one team maintains lots of microservices", this is nearly always an anti-pattern.
  - mike_hearn 2y ago
    Accountability and transparency go hand in hand, though. Teams would be able to debug together much easier if stack traces were propagated across RPCs, and good RPC frameworks can do that. Unfortunately when (ab)using HTTP+JSON for RPCs, good cross-service debugging is one of the first casualities.
    - jananas 2y ago
      I have a hard time imagining what that means but it sounds like it could be helpful for a project at work. Can you point to a source that elaborates on error propagation on rpcs?
fedeb95 2y ago
hiding stack traces is a bad practice and should be avoided unless you're in the last layer of the application (i.e. presentation to the user).
albertzeyer 2y ago
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 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 https://github.com/albertz/py_better_exchook#domterm Some more on text folding: https://github.com/PerBothner/DomTerm/issues/54 https://github.com/PerBothner/DomTerm/issues/54 https://gitlab.com/gnachman/iterm2/-/issues/4950 https://gitlab.com/gnachman/iterm2/-/issues/4950 https://github.com/xtermjs/xterm.js/issues/1875 https://github.com/xtermjs/xterm.js/issues/1875 https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/3 https://gitlab.freedesktop.org/terminal-wg/specifications/-/... https://github.com/vercel/hyper/issues/1093 https://github.com/vercel/hyper/issues/1093
CMDBob 2y ago
A stack trace (or even better, a minidump with the call stack!) is one of the most useful debugging things for me. Hell, the call stack in general is super useful to me! I can look at a stack trace, go "oh, function X is misbehaving after being called by function Y, from function Z", and work out what's gone wrong from the context clues, and other debugger info. As a game developer, with codebases that are big, semi-monolithic codebases, it's essential, especially when code crosses the gameplay/engine and engine/kernel barriers.
zokier 2y ago
Kinda related, but I feel it would be useful for log entries to include file/lineno and/or some unique identifier. Helps both pinpointing where some weird message comes from, and for searching for specific entries in the logs. Sure, you can grep the log message but it can be difficult if it has some templating/formatting going on, and it can be pretty easy to end up with non-unique messages.
- XorNot 2y ago
  Whats weird is how expensive this can be - i.e. to do it in Go requires invoking runtime reflection, whereas technically the compiler should be able to update the final numbers into the messages at build time.
creshal 2y ago
Stack traces are underrated, unless you're developing EnterpriseJavaSingletonFactoryAbstractionFactoryFactories, in which case they're buffer overflows on your poor log analyzer
someothherguyy 2y ago
Stupid clickbait headline for a famished article
deleted 2y ago
[deleted]
GuB-42 2y ago
I don't know if it is part of the reason but stack traces can be considered a vulnerability in some situations. Also, for "normal" errors, you shouldn't need a stack trace. For example, "file not found" is, from the point of view of the developer an expected situation and should be handled with the same amount of care as it the file was present. You don't dump the internals to the user when you have successfully opened the file, so don't dump them when you haven't. For unexpected errors (i.e. bugs), the crash, abort, panic, or whatever it is called in your language. These will usually give you a stack trace, or a core dump from where you can extract the stack trace and more. What I would wish for however would be a standard feature in languages to display a stack trace on command. Many languages have it, but even when they do, they could be more prominent. This way, if you encounter an unexpected situation you want to debug without crashing and without a debugger attached, you can call it.
harperlee 2y ago
My main problem with (jvm) stack traces is that they generally don't include information about the values that are passed to the function calls, so you get the structure of the code, but not the actual value that could help you reproduce the error. I know that once you deal with relatively complex objects that are not trivially serializable you get an address, which is not super useful, but in some codebases / problem areas you still could be getting a lot of information that gets lost due to that design decision.

96 points by zoidb 2y ago

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.

hinkley 2y ago
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.
miohtama 2y ago
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.

Chilinot 2y ago

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

karl42 2y ago
You could combine both by adding a stack frame each time the error is returned one level up. This could be done explicitly (cumbersome and not everyone will do it) or automatically by the language (weird magic, but useful).

the_mitsuhiko 2y ago

> 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. [1]: https://github.com/rust-lang/rust/issues/99301 https://github.com/rust-lang/rust/issues/99301

reseasonable 2y ago
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.

berkes 2y ago

Way 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?

hinkley 2y ago
Time travel debugging is the category, but I can’t help you much more than that with the tool names.
- reseasonable 2y ago
  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.
  - jeroenhd 2y ago
    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.
- iggldiggl 2y ago
  Time-travel debugging is something different – time-travel debugging means you can actually step backwards through the execution to try and see how you ended up with the bug. Merely being able to inspect the state of (local) variables further up the stack frame is a much more limited proposition, even if it can still be useful. > yet very often wished I had it (for […] javascript […] mostly) Both Firefox's and Chrome/Edge's devtools allow you to do that, don't they? Click on an entry in the stack frame and it takes to the corresponding code line and shows you the state of the variables relevant at that point.

logicallee 2y ago

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

TinkersW 2y ago

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

piva00 2y ago
Hard to break into the debugger for a production application running on hundreds of servers.
- TinkersW 2y ago
  Perhaps, but remote debugging is a thing, though triggering an auto break into debugger would be more complex.
  - piva00 2y ago
    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.
- Cthulhu_ 2y ago
  One can argue whether stack traces should be enabled for production (at least on all servers) given they're relatively expensive to create. Which isn't a problem if they're exceptional, but in a lot of cases they aren't.
  - xmcqdpt2 2y ago
    They aren’t equally expensive everywhere. They are cheap on the JVM.

montebicyclelo 2y ago

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

anonzzzies 2y ago

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.

rootnod3 2y ago
Oh yes. I haven't found any equivalent yet.

cm2187 2y ago

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

HdS84 2y ago
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.

rollulus 2y ago

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.

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

windward 2y ago

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

bob1029 2y ago

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.

pjc50 2y ago
> 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. Yes. People forget that the original concept of microservices, the AWS "everything must have an API", was to put in an accountability boundary across teams. Either the API behaves per its contract or it does not, you're neither expected nor really allowed to cross that boundary into the API to find out why it's doing that. In an environment which is correctly doing "each microservice is a different small team", that helps. In an environment which is doing "one team maintains lots of microservices", this is nearly always an anti-pattern.
- mike_hearn 2y ago
  Accountability and transparency go hand in hand, though. Teams would be able to debug together much easier if stack traces were propagated across RPCs, and good RPC frameworks can do that. Unfortunately when (ab)using HTTP+JSON for RPCs, good cross-service debugging is one of the first casualities.
  - jananas 2y ago
    I have a hard time imagining what that means but it sounds like it could be helpful for a project at work. Can you point to a source that elaborates on error propagation on rpcs?

fedeb95 2y ago

hiding stack traces is a bad practice and should be avoided unless you're in the last layer of the application (i.e. presentation to the user).

albertzeyer 2y ago

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 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 https://github.com/albertz/py_better_exchook#domterm Some more on text folding: https://github.com/PerBothner/DomTerm/issues/54 https://github.com/PerBothner/DomTerm/issues/54 https://gitlab.com/gnachman/iterm2/-/issues/4950 https://gitlab.com/gnachman/iterm2/-/issues/4950 https://github.com/xtermjs/xterm.js/issues/1875 https://github.com/xtermjs/xterm.js/issues/1875 https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/3 https://gitlab.freedesktop.org/terminal-wg/specifications/-/... https://github.com/vercel/hyper/issues/1093 https://github.com/vercel/hyper/issues/1093

CMDBob 2y ago

A stack trace (or even better, a minidump with the call stack!) is one of the most useful debugging things for me. Hell, the call stack in general is super useful to me! I can look at a stack trace, go "oh, function X is misbehaving after being called by function Y, from function Z", and work out what's gone wrong from the context clues, and other debugger info. As a game developer, with codebases that are big, semi-monolithic codebases, it's essential, especially when code crosses the gameplay/engine and engine/kernel barriers.

zokier 2y ago

Kinda related, but I feel it would be useful for log entries to include file/lineno and/or some unique identifier. Helps both pinpointing where some weird message comes from, and for searching for specific entries in the logs. Sure, you can grep the log message but it can be difficult if it has some templating/formatting going on, and it can be pretty easy to end up with non-unique messages.

XorNot 2y ago
Whats weird is how expensive this can be - i.e. to do it in Go requires invoking runtime reflection, whereas technically the compiler should be able to update the final numbers into the messages at build time.

creshal 2y ago

Stack traces are underrated, unless you're developing EnterpriseJavaSingletonFactoryAbstractionFactoryFactories, in which case they're buffer overflows on your poor log analyzer

someothherguyy 2y ago

Stupid clickbait headline for a famished article

deleted 2y ago

[deleted]

GuB-42 2y ago

I don't know if it is part of the reason but stack traces can be considered a vulnerability in some situations. Also, for "normal" errors, you shouldn't need a stack trace. For example, "file not found" is, from the point of view of the developer an expected situation and should be handled with the same amount of care as it the file was present. You don't dump the internals to the user when you have successfully opened the file, so don't dump them when you haven't. For unexpected errors (i.e. bugs), the crash, abort, panic, or whatever it is called in your language. These will usually give you a stack trace, or a core dump from where you can extract the stack trace and more. What I would wish for however would be a standard feature in languages to display a stack trace on command. Many languages have it, but even when they do, they could be more prominent. This way, if you encounter an unexpected situation you want to debug without crashing and without a debugger attached, you can call it.

harperlee 2y ago

My main problem with (jvm) stack traces is that they generally don't include information about the values that are passed to the function calls, so you get the structure of the code, but not the actual value that could help you reproduce the error. I know that once you deal with relatively complex objects that are not trivially serializable you get an address, which is not super useful, but in some codebases / problem areas you still could be getting a lot of information that gets lost due to that design decision.