Constructors for custom exceptions

Burk Hufnagel

Ranch Hand

Posts: 814

3

posted 12 years ago

In their SCJP/SCJD certification book, Kathy and Bert says:

Make Your Exception Classes with a String Constructor (As Well As a no-arg) for Providing Additional Meaning Every Exception class you develop should have both a no-arg constructor and a constructor that takes a String. Exception inherits a getMessage() method from Throwable, and it returns the String of that message, so you can pass that message back to your super constructor and then the catcher can query it for more information. The message�s main use, however, is to provide more information in the stack trace. So the more detailed your message (usually about the state of key parts of the system at the time the exception occurs), the more helpful it will be in diagnosing the problem.

Italics mine. I'm a bit confused by this. I think having a constructor that takes a String message makes sense, but I would also include one that takes a String message and a Throwable cause to support exception chaining. The no arg constructor has me puzzled though. What's the point of having it? No arg means someone could throw an exception with no message or cause associated with it. Am I missing something, or does this make sense to you (the reader) as well? Thanks, Burk [ March 19, 2004: Message edited by: Burk Hufnagel ] [ March 19, 2004: Message edited by: Burk Hufnagel ]

One reason I can think of is if someone wants to write a remoteable class (such as a web service) which can throw that exception, then it has to have a no-arg constructor just so it can be serialized from the server to the client.

I'm a bit confused by this. I think having a constructor that takes a String message makes sense, but I would also include one that takes a String message and a Throwable cause to support exception chaining.

I agree - I always included constructors which allowed throwable clauses.

The no arg constructor has me puzzled though. What's the point of having it? No arg means someone could throw an exception with no message or cause associated with it.

You may not have any meaningful comment to add to the exception I have a very vague recollection that this is a reflections issue. For example, you cannot call Class.forName() on a class that doesnt have a zero argument constructor. I have my doubts about this though (and with BillyBob's suggestion about serialization) because in both cases you would not be able to add a String after you have constructed the class. The javadoc for Throwable states:

By convention, class Throwable and its subclasses have two constructors, one that takes no arguments and one that takes a String argument that can be used to produce a detail message. Further, those subclasses that might likely have a cause associated with them should have two more constructors, one that takes a Throwable (the cause), and one that takes a String (the detail message) and a Throwable (the cause).

So it may even just be a convention held over from an earlier version of the JDK. Interestingly, the new assignments have the requirement:

Any unimplemented exceptions in this interface must all be created as member classes of the suncertify.db package. Each must have a zero argument constructor and a second constructor that takes a String that serves as the exception's description.

I have no idea whether this is just to try and get programmers used to the "convention", or to see if this is to see how well candidates can follow instructions which may not make sense . There are certainly many exceptions in the J2SE 1.4 JDK which do not have no argument constructors, so there is certainly precedent for not having them in the Fly By Night Services assignment. Regards, Andrew [ March 19, 2004: Message edited by: Andrew Monkhouse ]