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:
collection.map do |item| res = some_http_request(item) add_stuff_to_item(res, item) item ensure item end
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' item ensure item end end 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.
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.