the_mitsuhiko on Stack Traces Are Underrated

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

reseasonable 1y

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.

the_mitsuhiko 1y

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.

badmintonbaseba 1y

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

the_mitsuhiko 1y

Note how also in this stack trace you lose the information about where the main task was scheduled [1]. While you can stitch together the await points, it's much harder to find where tasks are originating. This is also true for `TaskGroup` where the actual call that schedules a task is lost. You will just find the eventual await, which might be the task group (which is good, since that would be structural concurrency), but often you just find nothing since it's not properly awaited or in a completely different place (eg: pending shutdown).

[1]: the important line is "main_task = loop.create_task(main())"

badmintonbaseba 1y

That's a good point. I would argue that both that line and the reported `loop.run_until_complete(main_task)` line are important, but then it becomes impossible to have a single linear trace when there are manually scheduled and waited on tasks mixed in.

At that point you have something like a "coroutine frame tree" instead of a "stack trace", where you potentially store multiple parent frames and source lines per coroutine frame. Could be presented something like:

  $ python3 test_stacktrace.py
  Traceback (most recent call last):
  * File "/home/user/tmp/test_stacktrace.py", line 22, in <module>
  |   main_task = loop.create_task(main())
  | * File "/home/user/tmp/test_stacktrace.py", line 24, in <module>
  |/    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

Yoric 1y

Maybe in your example, but I long ago gave up on having stack traces with any meaningful async Python code. Is it the frameworks' fault? Presumably. But the end result is the same for me. Which is a shame, because Python stack traces are really good, when they work.

vlovich123 1y

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.

bbatha 1y

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.

You need to use the actual `await` syntax to get an async stack trace in node. Callbacks and raw promise work can't be seen by the async stack trace implementation which hooks into `await` points.

johncolanduoni 1y

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.

the_mitsuhiko 1y

Only until you spawn it into an executor :(

Comments