Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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 havn'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?

share|improve this 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
add comment

4 Answers

up vote 2 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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