Local variables as accidental breadcrumbs
While working on Bugsink, I spend a lot of time thinking about how Exceptions typically happen, and what factors are helpful (or not) in quickly fixing them. Some of this time is spent while I’m doing RealProductDesign™, but most of it is right after I step back from fixing an actual error as it happened in Bugsink or one of the related projects.
This blog post is a reflection on those thoughts and experiences, focusing on how local variables play a crucial role in effective debugging, and what this might mean for my (or your) coding style.
TL;DR: Directly seeing the values for local variables in your stacktrace is invaluable for debugging – in fact it’s one of the main reasons Bugsink is so useful. However: what actually gets captured depends on how you write your code: simple functions with local variables are much easier to debug than complex classes or overly-inlined code.
Exceptions typically don’t happen where the error in your code is. In fact, they often happen a few lines after the actual error. Typically: one function’s output is passed to another function, which then raises an exception because of invalid input.
