That might be true I was just throwing out my approach. Personally
I'm not a huge fan of the @Provider mechanism as it's not intuitive.
You just have to know how Jersey/JAX-RS works and that there are these
magic provider classes that may be configuring behavior. I'd rather
keep things simple and use as much plain Java as possible. I don't
think the string-of-catches will be a problem upkeep wise and anyone
else can look at my code and pretty much understand what's going on.
Using the exceptionMapper would you have an individual mapper for
every exception type? Seems like a ton of boilerplate.
Chris
On Mon, Feb 22, 2010 at 9:32 AM, Moises Lejter <moilejter_at_gmail.com> wrote:
> 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.
>>
>