Hmm - if by "HTTP classes" you mean those annotated with JAX-RS/jersey
annotations, then I think Marc was talking about using ExceptionMapper
classes to capture the service-layer exceptions, then returning an HTTP
response with the proper status code and message, taken from those
exceptions. As a result, you would not need that "string of catch clauses"
- your HTTP classes would simply ignore exceptions, and concentrate on the
"correct" scenario, and the ExceptionMappers would be invoked by Jersey on
its own, when the HTTP class throws an exception that it doesn't handle
(namely, your domain exceptions from the service layer), and compute and
return the right error status code and message for you...
No string of catch clauses => more maintainable code?
Moises
On Mon, Feb 22, 2010 at 11:18 AM, Chris Carrier <ctcarrier_at_gmail.com> wrote:
> The approach I landed on was to keep the HTTP error handling as
> contained in the Jersey annotated endpoint classes as possible. So
> basically from my HTTP classes I delegate to some kind of service
> class layer. So if I am trying to post an account or something I
> would create an Exception maybe something like
> 'AccountCreationException', 'AccountValidationException' etc that get
> thrown from the service layer. Then in my HTTP class I simply catch
> those and map them to whatever status code I want
> (AccountNotFoundException -> 404 etc...). And since the exceptions
> were raised in the service layer they already contain a human readable
> error message. It keeps it pretty manageable because there is just a
> string of catch clauses that handle your HTTP error mapping.
>
>