Failing, loudly

| software engineering

I’m a simple guy: I want my locks to fail closed. Software, on the other hand, should fail spectacularly.

Recently, a coworker proposed a change that read something like this: do |item|
  res = some_http_request(item)
  add_stuff_to_item(res, item)

I opposed this change.

It’s too quiet here

First of all, this doesn’t necessarily work as intended, or indeed how it may be read at first blush:

def boom
  %i[a b].map do |item|
    raise 'boom'

ret = boom #=> RuntimeError: boom in `block in boom'
ret #=> nil

But more importantly, I oppose the intention. The intended behavior of this method is to fail quietly and swallow errors.

Hot take: that’s wrong.

Failing, loudly

Exceptions are not evil to be squashed. They’re like running a fever: it’s a way for the system to tell us something is wrong. We can then put them in our error tracking system, get notified when they happen, ascertain how many people they’re affecting and act accordingly.

In the case above, the intended behavior would be for the software to try and reprocess item, then forward the unprocessed version if something went wrong. While this isn’t strictly incorrect - the system would limp onwards from that state - it wouldn’t let us know that something was wrong. In that particular case, the only way we would get notified that something was amiss would be for the customer to tell us.

Customers are an error tracking system used by a confounding number of companies, but we’re not those companies. While I did that myself, I’d like to think my standards went up a couple notches since my freelance PHP developer days.

So, when the system thinks something is wrong, it should absolutely go boom. As loud as possible, too. Alarm bells ringing, if we have any of those. Only when we know that something is wrong, can we react. If the error was a nothingburger, we can add an exception to our reporting, or work around that case - we can do something if we know.

I guess that’s it for this one. Have a great day, people.

Wait, someone makes locks that fail open?

Yeah, there’s a company that makes document storage cabinets with battery-operated RFID card readers as the locking mechanism. There’s no physical key fallback and the battery compartment is on the inside, so the creative geniuses behind this product decided that in case the battery runs out, the doors just open. In other words, if you want whatever is in that cabinet, you steal it and wait.

This has nothing to do with exception handling, but its very existence bothers me.

Hero image by Thomas Staub from Pixabay

Built with ❤ by Paweł J. Wal in 2023. Hugo helped.

Blog contents, except where otherwise noted, are CC BY-SA 4.0. Code of this blog is MIT.

Toggle dark/light mode