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 E''''''xceptions (in a way that naming the thrower does not). 

Of course, you must do this reasonably well. 

'''Good example:''' java.lang.ClassNotFoundE''''''xception 

''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.  

'''Bad Example:''' java.lang.NoSuchMethodE''''''xception 

''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 
going on. 

 -- WilliamGrosso

''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...'

----

The java.lang.NoSuchMethodE''''''xception, in the case of the Beans, seems like
a good candidate for ConvertE''''''xceptions. They opted for ThrowDontCatch, but 
in doing that lost a vital piece of information. It be clearer thrown as a "java.beans.NoDefaultConstructor". -- RobCrawford

------

ClassNotFoundE''''''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''''''xceptionPerContext.

 -- BrianSlesinsky

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


----
CategoryException

CategoryNaming