Summary
Good exception design can be useful in communicating the semantics of an operation and improve method factoring. This requires looking beyond the mechanical compilation and to what each method means to its consumer.
Introduction
OSIDs strictly define the permissible checked an unchecked exceptions which may pass. They are straightforward in the most basic of method implementations. However, some semantic analysis is necessary when creating a chain of methods to help convey what may have gone wrong to your consumer or ultimately your end user.
Basic Examples
The Decorator
In a decorator pattern (same holds true for adapter patterns across instantiated OSID Providers), the same method is used in both layers. The method signatures line up and more importantly the semantics of the method are identical so the exceptions can just bubble through.
class AssetLookupLoggingDecorator
implements org.osid.repository.AssetLookupSession {
private org.osid.repository.AssetLookupSession next;
public org.osid.repository.Asset getAsset(org.osid.id.Id assetId)
throws org.osid.NotFoundException,
org.osid.OperationFailedException,
org.osid.PermissionDeniedException {
log(getEffectiveAgent() + " looking up " + assetId);
return (this.next.getAsset(assetId));
}
...
However, there may be a reason to catch an exception or two.
Jumping In The Way
The previous example logged retrievals even when it didn’t work. This example more accurately distinguishes successes from failures.
class AssetLookupLoggingDecorator
implements org.osid.repository.AssetLookupSession {
private org.osid.repository.AssetLookupSession next;
public org.osid.repository.Asset getAsset(org.osid.id.Id assetId)
throws org.osid.NotFoundException,
org.osid.OperationFailedException,
org.osid.PermissionDeniedException {
try {
return (this.next.getAsset(assetId));
} catch (org.osid.OsidException oe) {
log(getEffectiveAgent() + " could not get " + assetId + " because of " + oe.getMessage());
throw oe;
} finally {
log(getEffectiveAgent() + " looking up " + assetId);
}
}
...
This method adds nothing to the process of retrieving an asset so we don’t want to interfere with the exception chain. Re-throwing the same exception instead of creating a new one is the right choice when just needing a sneak peek.
This could have caught each of the NotFoundException, OperationFailedException, and PermissionDeniedException explicitly, but OsidException was a bit easier. All org.osid.OsidExceptions are checked exceptions declared in the method signatures. We cannot get any other kind of checked exception from getAsset() so the broader net is fine in this case (note that org.osid.OsidRuntimeException is like java.lang.RuntimeException but org.osid.OsidException is not like java.lang.Exception because it does not include org.osid.OsidRuntimeExceptions).
What about unchecked exceptions? The specification also explicitly permits org.osid.NullArgumentException and the runtime may throw a variety of org.osid.ProviderContractExceptions and org.osid.ConsumerContractExceptions. All of these exceptions result not from the operation of the code but from some kind of issue with the code itself. There’s no point in handling errors in code that is broken. In a running application, you may wish to catch them at your last net and open a jira.
In most cases, there is no reason to catch org.osid.OsidRuntimeException of any of its subclasses.