[C3] Error handling in REST controller

[Andreas Hartmann <an...@apache.org>]

Hi all,

I just noticed that if a handler method in a RESTController throws an 
exception and the sitemap doesn't contain an error handler, an empty 
response with status code 200 is returned.

IMO this is not good. I see two approaches to improve it:

A) The SpringRESTController sets the status code to 500 if an exception 
was thrown by the controller implementation.

B) The sitemap processor should catch the exception (I'm not familiar 
with the implementation details yet) and send an appropriate response 
(on a side note, it would be nice to be able to set the status-code 
attribute for a Reader).

I have to admit that the whole concept how the REST controller in 
combination with the sitemap should handle the request-response cycle is 
a bit unclear to me. Is the REST controller always in charge of the 
whole request-response cycle, up to setting the response status code? Is 
the handle-errors element in the sitemap obsolete when the REST 
controller is used?

IMO this would make sense, since the REST controller is much closer to 
the HTTP details than "classic" G-T-S pipelines, where more stuff 
happened in the sitemap (selectors for HTTP methods, serializers with 
status-code attributes).

Anyways, there should be a clear contract between the sitemap and the 
REST controller, something like:

* The REST controller is responsible for setting up the response, 
including error handling.

* The handle-errors clause kicks in if an error occurs in the REST 
controller itself.

WDYT?

-- Andreas


-- 
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01

Re: [C3] Error handling in REST controller

[Reinhard Pötz <re...@apache.org>]

On 12/19/2011 06:47 PM, Andreas Hartmann wrote:
> Hi all,
>
> I just noticed that if a handler method in a RESTController throws an
> exception and the sitemap doesn't contain an error handler, an empty
> response with status code 200 is returned.
>
> IMO this is not good. I see two approaches to improve it:
>
> A) The SpringRESTController sets the status code to 500 if an exception
> was thrown by the controller implementation.
>
> B) The sitemap processor should catch the exception (I'm not familiar
> with the implementation details yet) and send an appropriate response
> (on a side note, it would be nice to be able to set the status-code
> attribute for a Reader).
>
> I have to admit that the whole concept how the REST controller in
> combination with the sitemap should handle the request-response cycle is
> a bit unclear to me. Is the REST controller always in charge of the
> whole request-response cycle, up to setting the response status code? Is
> the handle-errors element in the sitemap obsolete when the REST
> controller is used?
>
> IMO this would make sense, since the REST controller is much closer to
> the HTTP details than "classic" G-T-S pipelines, where more stuff
> happened in the sitemap (selectors for HTTP methods, serializers with
> status-code attributes).
>
> Anyways, there should be a clear contract between the sitemap and the
> REST controller, something like:
>
> * The REST controller is responsible for setting up the response,
> including error handling.
>
> * The handle-errors clause kicks in if an error occurs in the REST
> controller itself.


I'm not sure if we should introduce special error handling for REST 
controllers. Wouldn't we have to do the same for all other sitemap 
components either?

If the author of a sitemap decides that he doesn't want to provide 
proper error handling, we should catch the error in 
o.a.c.servlet.RequestProcessor.sendSitemapResponse() and send "500 
Internal Server Error" so that the status code is correct. We should 
also log the exception there because AFAICS this isn't done anywhere else.

Additionally we can give a hint in the log files that an error has 
occurred but wasn't handled properly by the sitemap 
o.a.c.sitemap.node.PipelineNode.handleException().

-- 
Reinhard Pötz         Founder & Managing Director, Indoqa and Deepsearch
                         http://www.indoqa.com/people/reinhard-poetz.html

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard@apache.org
________________________________________________________________________

       Furthermore, I think Oracle has to honor the JSPA agreement.
     http://s.apache.org/JCPIsDead       http://s.apache.org/tck-trap