Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


Tip of the Day
Language: Java
Expertise: Intermediate
Dec 13, 2002

Exceptions are Objects


When a class designer believes that an exceptional condition is recoverable, the checked exception should be thrown. But, many programmers (and I am guilty of this as well) tend to forget that an Exception is an object, and thus its subclasses can have additional states/behaviors added to them. In most cases, Exceptions are thought of as just wrappers around messages that describe what went wrong.

However, exceptions can do more—and in the case of checked exceptions, they should do more. Since checked exceptions expect the caller to recover from exceptional conditions, they should provide information through additional fields/methods that the caller can use for that recovery.

For instance, say you have a method that builds a request object based on some byte sequence received from communication port:
 
	public Request getFromBytes(byte[] bytes)
	  throws InvalidMessageLengthException {...}

You throw a checked exception, because you expect the caller to recover from the situation by reading additional bytes from the communication channel. In order to provide the caller with more information, your exception might look like this:
 
class InvalidMessageLengthException
  extends Exception
{
...
  public int expectedLength() {...}
  public int actualLength() {...}
}

By calling the methods of the caught exception, the caller will know how many more bytes to read from the communication channel before attempting to call the method again.
Slava Dimitrovich
 
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date