The IBridge interface defines exceptions that each method in a connector might return. The exception thrown should reflect the condition that occurred. Most of the exception names are self-explanatory.
An extensive set of exceptions is included in the com.venetica.vbr.client package.
In some cases, an exception of one type must be caught while an exception of a different type is returned. For example, during a logon() call to a new connector, an API call to the repository returns a repository-specific exception. Because the logon() method signature defined by the IBridge interface throws a LogonException, you must catch the repository-specific exception and return a LogonException. This pattern of catching exceptions of one type and returning exceptions of another type can occur several times while an exception propagates to a client. Often, information is lost about the location and type of the original exception. Also, exceptions returned within an RMI call do not retain stack trace information when returned to the caller. To compensate for these situations, all subclasses of VeniceBridgeException optionally take a previous exception as an argument and store a string representation of that exception and the exception's stack trace information for later reference.
This sample demonstrates recommended exception handling techniques for connector methods:
public Content getContent(String contentID, String versionID)
throws NotLoggedOnException, PermissionDeniedException,
ItemNotFoundException, VersionNotFoundException {
try {
...
/* During processing inside this try{}
block, you should throw exceptions listed in
your method signature where appropriate.
These exceptions should not be caught by your
catch statements, but should filter through. */
...
} catch(MyRepositoryException ex) {
// MyRepositoryException is thrown by API calls to repository
String exceptionText = ex.getMessage();
DebugLog.log(bridgeInstanceID, this.getClass(), DebugLog.ERROR, exceptionText);
throw new ItemNotFoundException(exceptionText, ex);
} catch(RuntimeException ex) {
String exceptionText = "RuntimeException in getContent(): " + ex.toString();
DebugLog.log(bridgeInstanceID, this.getClass(), DebugLog.ERROR, exceptionText);
throw new ItemNotFoundException(exceptionText, ex);
}
}
Both catch blocks write exception information to the debug log. In addition, both catch blocks use exception constructors that take a previous exception as an argument. Because runtime exceptions appear as RemoteExceptions if left uncaught, runtime exceptions in each connector method should be caught so that the appropriate message reaches the client. Finally, do not implement a catch block for java.lang.Exception because the catch block will catch all exceptions and prevent the appropriate exceptions from filtering through to the client.
