12May The anti-pattern series: Exception-Handling
With kudos to a good article at Java.net and to the book AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. We get a good eye-opener on the often-touted handle-your-exceptions-directive from your team lead or software architect. In the my previous posts, I have mentioned that anti-patterns should not be left unnoticed in the design and development time. I am starting this series of blog posts to collect and summarize an anti-pattern that I am sure, some stray developer out there in the world might be blissfully ignoring. So here goes the first: about exception handling. For more details, kindly refer to the java.net article or to the book.
Exception Handling Anti-patterns:
- Log and Throw – don’t log then throw. Do only one thing.
- Throwing Exception – a good programmer knows this is a _big_ no-no
- Throwing the Kitchen Sink - if not throwing Exception is good, you might as well don’t throw a big gamut of checked exceptions
- Catching Exception – again, while throwing Exception is a minus point, catching Exception is as evil as it is
- Destructive Wrapping – you will lose your valuable stack trace with this… for example throw new NewException(oldException.getMessage()). Got it?
- Log and Return Null – not always wrong, but it is more elegant to throw the checked exception instead of returning null
- Catch and Ignore – well almost everyone is guilty of this… suppression of exceptions!
- Throw from Within Finally – leave the finally alone. Be sure that your finally{} block will execute as peacefully and completely as it can
- Multi-Line Log Messages – this will eat up a lot of your log resource
- Unsupported Operation Returning Null – if you don’t have an implementation (yet), throw an unchecked UnsupportedOperationException instead of forcing the caller program to handle null
- Ignoring InterruptedException – for you thread maniacs, try to do something when you catch this exception. The InterruptedException is a clue that your thread should stop doing whatever it is doing. For more of this, go study thread programming.
- Relying on getCause() – and why rely? Rely on the actual thrown checked exception instead. Relying on the getCause() is a symptom of a bad design.
May 12th, 2006 at 9:04 pm
Here’s my (partial) take on exceptions. It tries to strike at some of the causes of why people easily use exceptions incorrectly in Java.
A different part I need to cover some time is what should be done with the “throws” clause on method signatures.
May 12th, 2006 at 9:06 pm
That link I put on “take on exceptions” above is really hard to see. As a form of confession, I need to improve my link color, too.
May 15th, 2006 at 2:54 am
I am pretty rusty with my Java having learned it in the Java 1.0 days (early 1997). My idea of J2EE is ATG Dynamo which I learned in early 1999. So, I am pretty out of date.
What does the good book recommend we use if we can’t catch and throw? catch, log and throw? catch and handle?
Thanks!
May 16th, 2006 at 2:19 am
as these are antipatterns, it would naturally tell us to “do everything else, except these”
>> catch and throw… if catch, you might want to do some processing. meaning, if you catch, you’re taking the exception for yourself. otherwise, don’t catch it at all (and by defining a throws clause)
>> catch, log, and throw… think of the “log” as one of the activities in the catch. just like the rule above, don’t catch then throw.
>> catch and handle… don’t quite get what you mean by this.
cheers
if you need a book, i can recommend some