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

31–40 of 58 posts

Re: Stack Traces Are Underrated

#31

Post by karl42 »

Chilinot wrote: post #4

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…

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

Re: Stack Traces Are Underrated

#32

Post by CMDBob »

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.

Re: Stack Traces Are Underrated

#33

Post by zokier »

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.

Re: Stack Traces Are Underrated

#34

Post by XorNot »

zokier wrote: post #33

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.

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.

Re: Stack Traces Are Underrated

#35

Post by vlovich123 »

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…

I wish there was a mode to force Errors to automatically capture traces & print them as part of the chain on panic. Would save a lot of time when debugging & let you force libraries into supporting it.

Re: Stack Traces Are Underrated

#36

Post by Cthulhu_ »

piva00 wrote: post #12
TinkersW wrote: post #9

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.

Hard to break into the debugger for a production application running on hundreds of servers.

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.

Re: Stack Traces Are Underrated

#37

Post by pjc50 »

bob1029 wrote: post #24

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 exception…

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

Re: Stack Traces Are Underrated

#38

Post by iggldiggl »

hinkley wrote: post #6
berkes wrote: post #5

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

Time travel debugging is the category, but I can’t help you much more than that with the tool names.

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.

Re: Stack Traces Are Underrated

#39

Post by badmintonbaseba »

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…

Python asyncio supports meaningful stack traces through async functions just fine.

  import asyncio
  
  async def baz():
      await asyncio.sleep(.1)
      raise RuntimeError()
  
  async def bar():
      await asyncio.sleep(.1)
      await baz()
  
  async def foo():
      await asyncio.sleep(.1)
      await bar()
  
  async def main():
      await asyncio.sleep(.1)
      await foo()
  
  if __name__ == "__main__":
      loop = asyncio.new_event_loop()
      asyncio.set_event_loop(loop)
      main_task = loop.create_task(main())
      try:
          loop.run_until_complete(main_task)
      except KeyboardInterrupt:
          main_task.cancel()
          loop.run_until_complete(asyncio.wait([main_task]))
          pass
And then run: $ python3 test_stacktrace.py Traceback (most recent call last): File "/home/user/tmp/test_stacktrace.py", line 24, in loop.run_until_complete(main_task) File "/usr/lib/python3.10/asyncio/base_events.py", line 649, in run_until_complete return future.result() File "/home/user/tmp/test_stacktrace.py", line 17, in main await foo() File "/home/user/tmp/test_stacktrace.py", line 13, in foo await bar() File "/home/user/tmp/test_stacktrace.py", line 9, in bar await baz() File "/home/user/tmp/test_stacktrace.py", line 5, in baz raise RuntimeError() RuntimeError
Post reply on HN