An oldie but a goodie. The first ExceptionPattern
I ever learned.
Once you've decided to use an E
xception, the question remains: what to call it ? And the answer is: describe why the E
xception is being thrown. There are two main benefits to this:
- This piece of information, and the immediate stack frame, is often enough to solve the problem.
- Moreover, it highlights the essential similarity of many classes of Exceptions (in a way that naming the thrower does not).
Of course, you must do this reasonably well.
Thrown when an application tries to load in a class through its string name using: The forName method in class Class. The findSystemClass method in class ClassLoader. The loadClass method in class ClassLoader.
I have yet to run into this E
xception and not know why it was thrown.
Thrown when a particular method cannot be found.
This seems reasonable until you run into it in bizarre places. For example, JavaBeans
(and Serialization) require a constructor with no arguments. If you forget to include this constructor, and someone attempts to use your class
as a bean, they'll get a NoSuchMethodE
xception. The first time I ran into this,
it took me 20 minutes of staring at the stack to figure out what was
''It would help if they listed the class of the object they were trying to find the method on, and the name of the method...'
xception, in the case of the Beans, seems like
a good candidate for ConvertE
xceptions. They opted for ThrowDontCatch
in doing that lost a vital piece of information. It be clearer thrown as a "java.beans.NoDefaultConstructor?
". -- RobCrawford
xception is actually an example of a converted E
xception. The original E
xception was probably either FileNotFoundE
xception or ConnectionE
xception (depending on whether the class loader tried to load the class from a file or across the net.) And, as any newbie who's tried to install an applet will tell you, knowing which class wasn't found really doesn't tell you enough to figure out *why* Java can't find that class (most likely an error in the applet tag, or it's in the wrong directory).
The problem is that specifically named E
xceptions break abstraction - if we implement a class loader that loads classes from a RelationalDatabase
, we don't want to modify Class.forName() to throw SQLE
xception. So, we might have to "name the problem" in an attribute of the E
xception rather than the E
xception type, or by having more than one E
This is why it is important to allow for ChainedExceptions
. Some environments (e.g. MS CLI / .Net) support an InnerE
xception property. This allows you to not just "convert" an exception, but to provide the history / context that caused the converted exception. For example, in the ClassN
otFoundException example, the exception would have an InnerE
xception property whose value was ConnectionE
xception, which would provide the detailed information on why the connection failed (host unreachable, no tcp listener, protocol error, etc.). -- ArlieDavis