Introduction
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.
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 Decorator Example
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));
}
}
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.
However, there may be a reason to catch an exception or two.
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
}
}