The Haskell Unfolder Episode 29: exceptions, annotations and backtraces

Version 9.10 of GHC introduces an extremely useful new feature: exception annotations and automatic exception backtraces. This new feature, four years in the making, can be a life-saver when debugging code and has not received nearly as much attention as it deserves. In this episode of the Haskell Unfolder we therefore give an overview of the changes and discuss how we can take advantage of them.
Resources:
GitHub repo with the example code from the episode: github.com/wel...
The full exception backtrace proposal (most of which is now accepted and implemented): github.com/ghc...
Part 4 of the proposal, still under discussion (about "WhileHandling"): github.com/has...

[@TomSmeding]

Cool stuff! Previously one could already get backtrace info on exceptions in profiling builds with +RTS -xc, but that was very noisy in practice because it prints a backtrace for _every_ exception - and it's often not even clear which of those exceptions is the actual problem. Having an easy way to get good backtraces for mostly only the exceptions that matter is definitely a boon for debugging!

[@johnwalker7422]

Thanks for another super interesting vid. Definitely upgrading my ghc version soon

[@danieldiaz6025]

Great video. I was trying "annotateIO" in a program run with runhaskell/ghci and I didn't saw any annotations. They only appeared when running the compiled program. I suspect it's because the "losing annotations when re-throwing" effect described at 9:50.

[@edskodevries]

Ah, yes, perhaps I should have mentioned that -- I also noticed that it doesn't work in ghci. I'm actually not entirely sure why! I suspect that it might simply be that the exception handler used by ghci has not been updated. Perhaps this should be a ghc ticket.

[@lkbasgiohbasg]

thanks for making this! is there some way to use this to get a backtrace from an operation that's in an infinite loop seemingly? I tried throwTo to that thread and catching higher up, but the ExceptionContext is empty

[@well-typed]

Good question. Unfortunately, I think the answer is no: first, throwTo has not been modified to collect backtraces, but even if it did (you could write your own version that did, I suppose), the backtraces that it would collect would point you to the throw, not where to the point in the code that was looping prior to being interrupted by the exception. Perhaps you could try running your code in gdb, interrupt it during the looping, and then use DWARF information (see www.well-typed.com/blog/2020/04/dwarf-1/ and follow-ups for some information) -- though perhaps this could be an episode on its own right :)

[@lkbasgiohbasg]

Thanks, ya I did try setting a breakpoint as close to the problem as I could, which worked; but I couldn't figure out how to step through reliably/efficiently since it's one Haskell thread we're interested in