Whenever I learn a new programming language, I start with the list of “reserved keywords” for the language.
For example, the reserved words in Python are:
and del from not while
as elif global or with
assert else if pass yield
break except import print
class exec in raise
continue finally is return
def for lambda try
This list provides me with a helpful starting point for understanding what features are already built into a language, and what names I need to avoid.
But one keyword that I’ve discovered, and which has heretofore been undocumented (documentation being what it is), is the keyword explode. It’s available in all programming languages. And I use it as a simple sanity check - the most important of the programmer’s tools.
(That and break is already taken).
Troubleshooting the elaborate mechanisms of a software system can feel more like descending into the anxiety dream of a confused cartoonist than the awesome crystal palace of Kubla Khan.
That sunny dome! those caves of ice! – Coleridge
We need a way to check our sanity – debug the table and chairs of our reality. Make sure our conceptual foundations are solidly intact before we dig any deeper into the soup (depicted).
Enter the keyword explode. Throw it down at any point in your code, and then pray it brings your program to a wrenching halt. If it does, you keep on trucking. Sanity intact. If it doesn’t. Well now there’s something! That code never runs!
I mean, I love what you did with the place. All the design patterns, and the upholstery! It’s really come together. But boy you look silly with that rug pulled-out from under you!
But Nathan, you might say, why not use proper debugging tools likebyebug or debugger? Aren’t those tools way more powerful?
Because now you have two problems - the original problem, and a tool that requires its own training in the dark arts. I don’t need night vision goggles to fall down a flight of stairs. The goal here is to “fail loudly” and to fail immediately.
But Nathan, you cry out, you’re just throwing a ReferenceError or a NameError. You may as well be writing flitterbik or afs;dlfiauwe!
To which I calmly respond: explode is a verb, not a mythical flying squirrel or randomly typed gibberish. Naming things is hard. Intentions are important. I want my code to be readable. I want my code to explode.
How do you use explode in practice? Here’s an example involving a form submission.
When an HTML form is submitted to the server, the convention is to follow the pattern of “Post Redirect Get”. So when I submitted the parrot registration form (A), and I ended up back on the parrot homepage (C), I can only assume that my parrot was successfully registered before redirecting (B)!
Hypothesis: A → B → C
But the parrot isn’t in the database! Something must be wrong with step B!
Before we go any further. Just do me a favor: prove that B happened. Make B fail! Stop your program dead in its tracks and make B explode!
Hypothesis: A → B explodes? ⥇ C
No explosion! That means we never get to step B! And somehow we still got C! What now?
Hypothesis: A → ??? → C
What’s happening in step A that we we never get to step B? Is something wrong with our HTML form?
Hypothesis: A? → ??? → C
Eureka! I’ve got it!
Hypothesis: C
We mistakenly used the GET method instead of POST in our HTML form. That means steps A and B never happen! We’ve been skipping straight to getting the parrot homepage (C).
Our mental model didn’t match the reality of the software system, and the actual sequence of events.
And that, all to often, is the correct answer.
related ideas: