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.