Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com

Exceptions to the programming rules, Part 2

Incorporate Java's throw-object/catch-object exception-handling technique into your Java programs

By Jeff Friesen, JavaWorld.com, 04/05/02

  • Print
  • Feedback
.

Page 3 of 8

Now that you know something about StackTraceElement, that class's methods, and what stack-trace data looks like, you probably want to experiment with that class. But first, you need to understand a few more concepts. After presenting those concepts, I give you a chance to work with StackTraceElement.

Extend the exceptions class hierarchy

The exceptions class hierarchy includes a rich assortment of exception classes. When you need an exception class, you should first search that hierarchy for an appropriate class. If you cannot find an appropriate class or if you need a class resembling an existing class, you extend that hierarchy with a new class. Where does the new class fit within the overall class hierarchy? You must ask yourself if the class describes a checked exception or an unchecked exception. Assuming the answer is checked exception, the class appears within the Exception subhierarchy -- but not within that subhierarchy's RuntimeException portion. However, if the answer is unchecked exception, the class appears within the RuntimeException subhierarchy. Because you shouldn't handle unchecked exceptions that describe JVM failures, ignore the Error subhierarchy. To clarify this discussion, I present the following two examples:

  • You design an email library. That design reveals a pair of static methods that send and receive email messages. The send method uses Simple Mail Transfer Protocol (SMTP) to send an email message by engaging in a simple dialog of text-based commands and responses. Similarly, the receive method uses Post Office Protocol 3 (POP3) to receive an email message, using the same command/response-oriented dialog. Responses indicate success or failure. To describe failure, you create a pair of exception classes, one that describes SMTP failures and one that describes POP3 failures. Because responses -- from the SMTP and POP3 programs that communicate with the send/receive methods -- include response codes with human-readable messages, you store the message in your exception classes' Throwable layer and record the integer-based response code in a private field of each class. You avoid duplicating response code fields by introducing a generic superclass that declares that field and extendes that class with POP3 and SMTP exception subclasses. The following code fragment demonstrates:

    class EmailException extends Exception
{
   private int responseCode;
   EmailMessage (int responseCode, String message)
   {
      // Call Exception(String message), which calls Throwable(String message).
      super (message);
      this.responseCode = responseCode;
   }
   int getResponseCode ()
   {
      return responseCode;
   }
}
class POP3Exception extends EmailException
{
}
class SMTPException extends EmailException
{
}


    EmailException extends Exception because sometimes SMTP- and POP3-related exceptions arise from reasons other than flawed code -- perhaps the SMTP or POP3 program stops running during a communication session. As a result, POP3Exception and SMTPException identify different checked exceptions. (I'll discuss email, POP3, and SMTP in a future article.)

  • Print
  • Feedback

Resources