May 29, 2008 @ 9:40 pm
Exceptional Metadata
Exceptions are an important part of any programming language, especially Java. Java has two types of Exceptions. No, not checked and unchecked, but rather useful and useless. The utility of the Exception is up to you, the developer. What am I talking about? Bear with me, read on, and please share your comments at the end.
Core data
Exceptions are comprised of some sort of primary data, for example, the name or type of Exception, and maybe the exception’s message. Take, for example, a ConnectionTimeoutException.
You, as a developer, have a pretty good idea as to what is going on when you see this at the top of the stack trace. You may be able to read the message, if the developer provided one, and get a little more information about the exception.
/**
* Signals that a timeout occurred while opening the socket.
*/
public class ConnectionTimeoutException extends IOException {
/** Create an instance */
public ConnectionTimeoutException(String message) {
super(message);
}
}
Default Metadata
If you read a stack trace or hack the exception’s API, you can even get some more information about the it. Such as the Class that threw the Exception, or the line number where the Exception occurred. You might be able to review the hierarchy of the class to garner some information. For example, this ConnectionTimeoutException extends from IOException. That tells you something.
The Problem
The problem with this type of Exception is that someone, like a developer, needs to review this information in order to track down the cause of the issue. That means locating the stack trace, and determining the parameters and other configurations that were present at the time of the Exception.
Java, however, and most any other language, provide a means for supplying pertinent metadata when an Exception occurs. They are called properties, getters and setters, or mutators. You, as the designer, just need to include those properties when you design the class.
Example
Consider the ConnectionTimeoutException. Wouldn’t it be nice to know the source and destination URIs of the connection? And what the timeout value was?
/**
* Signals that a timeout occurred while opening the socket.
*/
public class ConnectionTimeoutException extends IOException {
private long timeout;
private String source;
private String destination;
/** Create an instance */
public ConnectionTimeoutException(long timeout, String source, String destination) {
super("failed to connect to " + destination + " within alloted " + timeout + "ms");
this.timeout = timeout;
this.source = source;
this.destination = destination;
}
public long getTimeout();
public String getSource();
public String getDestination();
}
Would you agree that the Exception that knows the timeout value and destination URI is more valuable to you, the developer, than some Exception with an arbitrary message that the designer may or may not have populated with relevant information?
Benefits
The resulting Exception implementation provides a constructor requiring specific values. The developer who consumes this Exception no longer needs to come up with some arbitrary message. He or she just needs to provide the requested parameters, which is known or can be read from some HttpClient implementation.
The developer who is catching and dealing with this ConnectionTimeoutException now has a few more options. Perhaps an error message will be displayed. The developer can write a custom message and use the timeout property to notify the end user what the timeout was. The developer doesn’t need to parse it from a String message property.
If the code throwing the ConnectionTimeoutException is a framework to be used by other developers, the developer has a lot more options to handle this Exception. Perhaps they are writing a GUI for your tool and can now provide their end users with more information.
Metadata in the Real World
I decided to write about this topic after a user of our Architecture Rules (Assert your Architecture!) open source software asked us to enhance our Exception APIs.
Our CyclicRedundancyException simply contained a message that described a package by its name, and then listed all of the packages involved in a cyclic dependency with said package.
...architecturerules.exceptions.CyclicRedundancyException: cyclic dependencies found: -- test.com.seventytwomiles.services | | | |-- test.com.seventytwomiles.model | | | |-- test.com.seventytwomiles.dao.hibernate | | -- test.com.seventytwomiles.model | | | |-- test.com.seventytwomiles.services | | -- test.com.seventytwomiles.dao.hibernate | |-- test.com.seventytwomiles.services
steven.devijver asked that we provide an API to retrieve a List of the packages involved in the cycle. This way Steven can construct his own message, or wrap the data in his own domain Exception, or whatever else he had in mind. We accommodated him by providing a Map containing a key (package name) and value (List of package names involved in a cyclic dependency) pair. This should be useful when we go to write the Maven 2 plugin report for this tool.
As another example, we inherited a DataFinderException in another project we’re working on. The only constructor for this Exception was a String named message. We introduced a new constructor and two properties — name and value — and getters for each. Now, the code that constructs DataFinderExceptions no longer needs to build some complex message with a StringBuffer before throwing the Exception.
StringBuffer message = new StringBuffer();
message.append("Could not find entity with");
message.append("userId");
message.append(" = ");
message.append(userId);
throw new DataFinderException(message.toString());
became
throw new DataFinderException("userId", userId);
A cleaner execution, fewer lines of code, and useful metadata that can be passed on to the end user, logged, or handled eloquently.
How do you design your Exceptions to provide useful metadata? Can you think of any Exception in the JDK that provide such metadata?
Filed under Architecture, Architecture-Rules, Software Development Permalink · 2 Comments »
