Rethinking the SlingException
Created: 23. December 2007
Inspired by Barry Ruzek's article Effective Java Exceptions, I went out to revisit the exceptions we have defined in the Sling API. This is what I came out with:
- We have 4 Exceptions, all of which are checked exceptions
SlingExceptionis a base exception and is declared almost everywhere
SlingExceptionand is not declared to be thrown anywhere
- We have two documented possibilities of throwing a runtime exception: The
AccessControlExceptionpossibly thrown when accessing a resource through the
Thinking about these (checked) Exceptions, I propose to change the Sling API as follows:
RuntimeExceptionand is used as the base exception for all exceptions defined by the Sling API.
HttpStatusCodeExceptionis removed. Status codes are better reported back to the client using
ResourceNotFoundExceptionwhich may be used by scripts and servlets to report a missing resource.
QuerySyntaxExceptionthrown from the
SlingScript.evalwrapping and further failure cause.
ServiceNotAvailableExceptionand the respective
ServiceLocator.getRequiredService: The method and thus the exception are probably not very usefull. Rather the
ServiceLocator.getServicemethod should be used and the result checked for
SlingException. These exceptions are used to wrap
ServletExceptioninstances to be able to forward them as runtime exceptions to the appropriate error handling.
This change also has an influence on the implementation of the Sling API:
- The main point is the handling of the
SlingExceptionin the Sling main servlet.
- Other locations catching
Exceptionshould be revisited to make sure no
SlingExceptionis swallowed and not treated correctly.
Another point with the Sling main servlet is, that it is important to not call error handling servlets from included requests but only from the topmost request.
The proposed API changes can be evaluated in the Sling whiteboard at http://svn.apache.org/repos/asf/incubator/sling/whiteboard/fmeschbe/effective_exceptions