Bad programming advice – don’t use exceptions

Kristian Dupont Knudsen has written a top 10 of programming advice not to follow with his rationalisation for each one. Being a programmer I thought I’d chip in with my 2 bits.

Joel recommends not using exceptions because they are “invisible in the source code” and that they create “too many possible exit points”.

His recommendation is to return error values when thing go wrong just like C does. This solves neither of the two problems he mentions and creates some new ones;

  • Passing an extra ‘error’ parameter to a function or use part of its return value
  • Keep track of the various error codes and what they mean
  • Newer libraries may return new errors that your code wasn’t written to handle and so your code will continue ignorantly
  • Forget an error and you’ll continue as if nothing went wrong…

I have to agree with Kristian on this one — Joel’s advice just makes no sense. Exceptions are a much superior solution to a difficult problem.

While I think Java went overboard in each method declaring what it might throw and needing to ensure you accept that C#‘s balance seems just right.

Throw exceptions when your method can’t do what it says on the tin but exceptions should be just that — the exception. Don’t ever throw them to signify some additional or inconsequential condition.

[)amien

2 responses to Bad programming advice – don’t use exceptions

  1. Avatar for

    Information is only used to show your comment. See my Privacy Policy.

  2. Avatar for Spyros

    I strongly disagree with Joel. Actually, you can create separate exception modules that inherit from your base class in order to make the exception code more manageable. Returning error codes is i think a very messy solution since after a while your code will just be overbloating with your own error handling routines.