What’s so hard about exceptions?

I keep wondering… Why is it actually so hard to handle exceptions correctly?

There are a few ground rules to follow and still people tend to overcatch or throw far too general exception types. As a recent empirical study suggests, this seems to be a general problem throughout software development. There is a brief, very well written guideline for .NET development, I keep waving at my team. I bet there is a similar guide for Java as well – any suggestions?

But I think the problem with exceptions is not just some guidelines that should be followed. Not every developer (and certainly not every customer) is comfortable with the ideal of error that may pop up from out of nowhere. Errors are silently suppressed for the better looks. But missing functionality cannot be hidden. If it doesn’t save, it doesn’t save and I certainly want to know that…

Logging is a way, but there is no path around exceptions in object-oriented programming. Taken that, there is also no way around a fail fast ideology. If something has gone wrong and I cannot do anything about it, it’s best to tell the world and not to brush it under the carpet. That’s also the best way to learn, by the way.

So, the first thing to establish proper exception handling seems to be the introduction of a culture of openly accepted mistakes. “Anything we find now, we won’t find later on.” should be the new motto.

2 thoughts on “What’s so hard about exceptions?”

  1. It all kind of depends on what kind of a system you are building, though… I’ve recently worked on a middleware system which certainly does not act in a fail-fast way:

    * it acknowledges basically every request
    * it logs exceptions and tries to recover if at all possible
    * it has multiple ways to store requests which have not yet made it to their final recipients

    There is infrastructure in place to monitor the log files: exceptions are logged in categories, and for each category there are instructions for the support teams (from “can be ignored” up to “report to a database administrator IMMEDIATELY”).

  2. Sure thing, middleware systems are a different cup of tea. What I had in mind while writing this post were more the kind of systems with (mostly) direct user interaction.
    But as you said, there are systems in place to inform the proper stakeholder of the exception that has occurred. As long as it is not fatal (Recovery queue unavailable or such), you are dealing with exceptions out of process. There is no need to display a big red warning to the end user, if there is a operations team capable of dealing with the issues that may happen.
    Correct me if I’m mistaken, but for the scope of the request, you are doing a fail fast as you seem to be reporting immediately to the support team.

    The kind of system is surely an issue to consider when deciding for the right kind of error reporting mechanism. In any case systems have to report anomalies and impediments in order to keep themselves operable.
    Even in user-centric systems there is no need to inform the end user about minor issues.

Comments are closed.