Comments on: The Bad Practices of Exception Handling

By: Joep

Joep — Tue, 10 Nov 2009 19:48:24 +0000

Lol, your last two posts are quite the “ah the world” and subsequent “oh the world”.

By: Hans-Eric

Hans-Eric — Mon, 09 Nov 2009 08:49:51 +0000

@Veera
I agree – obviously

By: Hans-Eric

Hans-Eric — Mon, 09 Nov 2009 08:31:14 +0000

@Mike Stone
Thank you for your comment Mike.
In the case of Java you’re probably right (it has been a long time since I had the pleasure of working in that great language), but in the case of C# fatal exceptions inherits from the Exception base class (via SystemException in between). That’s why I think catching Exception is a bad idea, except of course at your program’s entry points to implement your own unexcpected exception handling strategy.
And, of course, “a second or so” was an exageration, but not impossible in some cases. It depends on the situation, the depth of the stack trace etc. Anyway, that’s not the biggie for me.

By: Veera

Veera — Fri, 06 Nov 2009 08:45:51 +0000

‘eating’ exceptions is always bad. It destroys the entire stack trace and make the software maintenance, a nightmare.

By: links for 2009-11-05 | blog@alessandrobozzon.org

links for 2009-11-05 | blog@alessandrobozzon.org — Fri, 06 Nov 2009 00:31:58 +0000

[...] http://www.hans-eric.com » The Bad Practices of Exception Handling (tags: java programming) [...]

By: Mike Stone

Mike Stone — Thu, 05 Nov 2009 19:43:27 +0000

At least with the case of Java (and I suspect other popular languages), fatal exceptions tend not to actually be Exceptions. For example, OutOfMemoryError is an Error, which itself is a Throwable. You won’t be able to catch an Error by just catching Exception. Also, Error’s are not checked exceptions, so the compiler will never force you to deal with such fatal exceptions.

Personally, I feel catching a general Exception is fine (if you handle it properly and not just swallow it), but catching Throwable or Error should be considered a big risk.

Also, your comment “Throwing an exception with all that’s involved, like building a stack trace, will cost you a second or so” I think is incorrect. Yes, exceptions are costly (to throw), but they will NOT cost you a second or so. Do some performance tests if you don’t believe me. The key point about considering performance with exceptions I believe is to avoid using them when it is the common workflow. If you are using an exception to regularly break out of a loop, or indicate a common situation in your code… that is when you might start hitting performance costs because of them. Reserve them for truly exceptional conditions and you should be fine.

Otherwise, good post!

By: Hans-Eric

Hans-Eric — Thu, 05 Nov 2009 07:44:37 +0000

@Al Katawazi
I guess that’s the extreme implementation of catching late, the third rule of Effective exception handling.

By: Hans-Eric

Hans-Eric — Thu, 05 Nov 2009 07:36:31 +0000

@Bob Santos Great tip Bob. I haven't thought of it that way myself but it makes perfect sence.

By: Al Katawazi

Al Katawazi — Wed, 04 Nov 2009 14:39:48 +0000

For web development I pretty much has stopped using exception handling entirely. Custom error page pretty much handles everything, I just have an ovveride method that records the error and lets it continue regardless of its location in the application. You wouldn’t believe how much code bloat it destroys.

By: Bob Santos

Bob Santos — Wed, 04 Nov 2009 13:03:30 +0000

@George Just be sure not to overuse them. What I keep in mind when handling exceptions is you handle them to give users an idea about why something happened. Exceptions are primarily for users not us developers. Think of the users first then you as the developer.