Sounds good to me, but I would make 500.js and Throwable.js (as the
catch-all-solution) interchangeable, because having GET.js PUT.js
DELETE.js POST.js 404.js 401.js and Throwable.js looks like breaking a
pattern if you just need unspecific, but user-friendly error handling.
regards,
Lars
On 18.12.2007, at 08:53, Felix Meschberger wrote:
Hi all,
Prompted by a proposal in the Chickens, eggs and stars thread [1], I
propose a revised error handling concept for Sling. First, though, I
present the current implementation.
Current implementation
----------------------
Currently Sling (the core project) defines a ErrorHandlerServlet. This
interface may be implemented by error handlers and registered as OSGi
services just like any plain Servlet. In case of an error
(HttpServletResponse.sendError or an uncaught Throwable), Sling core
kicks in an error handler which calls the canHandle method of each
registered servlet in turn.
For an error with status code a series of status values is checked
against the servlets until a servlet can handle. The series is defined
as ( sc, (sc/10)*10, (sc/100)*100, 0 ) e.g. for the status 413 the
series would be ( 413, 410, 400, 0 ). Sling core contains a default
error handler servlet which replies true for the last entry (0).
For an exception to be handled the class hierarchy of the exception is
checked. For a FileNotFoundException, the classes
FileNotFoundException,
IOException, Exception, and Throwable are checked. The Sling core
default error handler replies true for the Throwable class.
Proposal
--------
This implementation is working but it is rather limited as all 404
stati
are handled by the same handler regardless of the actual request.
Starting from the proposal on the dev list, we could resolve the error
handler servlet or script just like any request handling servlet or
script.
The error handler creates a temporary SlingHttpServletRequest wrapper
whose getMethod() implementation returns the status code or Throwable
thrown. With this wrapper object the same resolution process takes
place
as for a normal HTTP method. If no servlet or script can be resolved
the
default error handler is used (instead of the normal default servlet).
The call to the error handler script or servlet is done using the
unwrapped SlingHttpServletRequest, that is the getMethod returns
actual
request method. Also the usual request attributes are set as defined
in
the Servlet Specification.
A handler for a status code is only searched for the exact status
code.
A handler for a Throwable is still searched through the class
hierarchy,
which is line with catch clauses, which also support the class
hierarchy.
WDYT ?
Regards
Felix
[1]
http://www.mail-archive.com/[email protected]/msg01320.html
--
Lars Trieloff
[EMAIL PROTECTED]
http://weblogs.goshaky.com/weblogs/lars
