Hi,
Am Dienstag, den 18.12.2007, 12:47 +0100 schrieb Lars Trieloff:
> 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.
So, the resolution process would be :
(1) for status codes:
Servlet s = resolveScriptOrServlet(code);
if (s == null) {
s = resolveScriptOrServlet(500);
}
if (s == null) {
s = defaultErrorHandlerServlet;
}
(2) Likewise for Throwables it would be:
Class<?> tClass = throwable.getClass();
Servlet s = null;
while (s == null && tClass != Object.class) {
s = resolveScriptOrServlet(tClass);
tClass = tClass.getSuperclass();
}
if (s == null) {
s = defaultErrorHandlerServlet;
}
Right ?
Regards
Felix
>
> 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
>
