Comments on: Exceptional Java - Less than perfect exceptions hierarchy

By: Leo

Leo — Fri, 11 Jul 2008 11:04:14 +0000

I think that this issue is not so grave as you present it here. An Error should never be thrown by an application but by the JVM only (e.g. an OutOfMemoryError). So you should never inherit from Error anyway, neither directly from Throwable. The rule is simple: For unchecked custom exceptions, inherit from RuntimeException. For checked custom exceptions, inherit directly from Exception or one of its other subclasses.
APIs that throw Exceptions are indeed bad, but that’s clearly an error in the API. Unfortunately there are developers who just won’t understand this (I once tried to explain it to one, but she just didn’t get it). If it causes grief to such developers then, well, may it be so.
With well-designed APIs (yes, they do exist) these points cease to be issues.

By: Daniel Pietraru

Daniel Pietraru — Sat, 10 May 2008 21:37:10 +0000

I think Java had an unexpected level of success even for its designers. Some of the APIs and other design decisions had a bad start and then the success forced backwards compatibility decisions. I think though Java’s success was caused by:
1. Garbage collection
2. Checked exceptions
3. Continuation of the C/C++ syntax

and maybe it deserves the first place…

4. Huge effort invested in the libraries

By: Shams Mahmood

Shams Mahmood — Sat, 10 May 2008 05:34:44 +0000

I agree, this checked and unchecked exception hierarchy leaves a lot to be desired.
Really good point about swallowed exceptions, but it is more of a bad api design to cause such scenarios.

By: Casper Bang

Casper Bang — Fri, 09 May 2008 19:24:17 +0000

Good post (even if I am no fan of checked exceptions). I completely agree, it takes a while to understand the confusing hierarchy. I often think the whole way we currently handle exceptions could need an overhaul. Have you seen the proposal by Collin Fagan?

http://aberrantcode.blogspot.com/2008/03/try-and-try-again.html