Raise Understanding

Klaas van Schelven; March 17 - 2 min read

Man blowing something up — Sometimes the best way to understand what's going on is to blow some stuff up

Here’s a typical debugging scenario: you tweak the code, restart everything, but still – no difference. After 3 changes and some head-scratching you reach out to “this one simple trick”:

raise Understanding("?!")

No need to dig through logs, set up a debugger, or wonder whether you’re changing the wrong file. Just insert a raise statement and see what happens.

If your program crashes at that exact spot, the line was executed. If not, the code path never reached it: Maybe the browser where you’re expecting to see the changes is still pointing at the production environment instead of localhost, your code is cached, or the problem is that the code that’s causing the issue is somewhere else in your codebase than you thought.

This “trick” is useful when something isn’t behaving as expected, but you don’t know whether the issue is in the logic or if the code simply isn’t running at all. Instead of guessing, a well-placed exception settles the question immediately. It also works as a quick way to trace execution flow: each exception comes with a stack trace, telling you exactly how the code got there.

A side benefit: if you use a non-existing exception type, like raise Understanding(), your linter and IDE will immediately highlight it as an error. This makes it easy to spot and remove before committing. And if you have any linting set up as part of your CI/CD, it will catch it there too.

It also has the benefit of showing up like 'Understanding' is not defined, which might feel uncomfortably accurate.

When combined with running your Error Tracking in Local Development raising an exception not only confirms that the line you care about is being hit, but also captures all local variables at that point when it is. This makes debugging faster, since you get immediate context on what was happening instead of manually inspecting variables.

Simple trick, fast results. Just remember to remove or comment out these raise statements before shipping your code. As funny as raise Understanding() might be in a development session, your coworkers and users probably won’t appreciate it.