My team recently inherited a project from a team where the amount of developers dropped so low they had to offload some work. One of the projects we inherited was a project littered with nested code, and awful exception handling (Exceptions were in effect handled as goto statements and thus used as a part of the normal program flow.).

All in all it was a hairy code ball someone had been coughing up for a few years.

Now we've been having a few team guidelines in place for quite some time, but all of the regards to the structures of objects, coding styles and what not. But we haven't covered exception handling.

So I'm wondering if you have any guidelines in your teams regarding exception handling, and if so how you enforce them?

closed as primarily opinion-based by durron597, Ixrec, jwenting, user40980, ratchet freak May 11 '15 at 11:33

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • You mean social enforcement or technological enforcement? There are lots of static code analysis tools for detecting abused Exception patterns. – MatthewMartin Dec 21 '10 at 15:05
  • Well both really. – Morten Dec 21 '10 at 18:49
  • It may be more straightforward to refactor the code to check preconditions first, and return from function early if any precondition is not met. Also, a number of prominent gurus consider finally (rollback logic) to be the more valuable part of an exception handling system. – rwong May 14 '11 at 10:44

Although they aren't official guidelines on any team I've ever been on, I feel that exceptions should only be used for truly exceptional conditions, or when you absolutely (for some reason) have to throw up your hands and let your caller (or bubble up from your current point, potentially all the way to the user) know that there's absolutely no way that a particular component can function under the current conditions and it's not possible to recover without some kind of outside (other module or user) intervention.


We don't have specific exception handling rules for our team, except the usual ones: don't use exceptions for 'normal' behavior, don't just silently swallow exceptions, etc.

Static ananlysis may help you catch some of those (depending on the language you use) but you'll be safer with code reviews.


Currently we don't have explicit guidelines, mostly because nobody in my team does it wrong. (Unlike many other topics, there is a general consensus when and how exceptions should be used)

But I would definitely implement them the same day I see an exception abused as a goto.


I think that exceptions should reamin Exceptions. I think its abusive and generates overhead when using exceptions as a workflow in your code. So, keep them verbose, and use only when something unexpected happened.

Note: tray to avoid the most common mistackes, like not passing the connection database to a function, or things like that. But rather use them when the primaryKey does not exists and you need it to do something.


I feel sorry for you that you had to inherit code from people who abuse exceptions to be goto-like statements.

I always attempt to catch them when any user input or something beyond my control can happen (ex: IOExceptions), but anything that could be a coding error (ex: NullPointerException) is something I'd try to catch with asserts early in development.

The performance hit from that kind of coding is a huge negative. I wonder if the company was shrinking due to terrible developers getting themselves into a mess beyond understanding...

Not the answer you're looking for? Browse other questions tagged or ask your own question.