Hmm - I would have thought it would go the other way ...
Using the "string of catch clauses", there is boilerplate in every class
that can run into a specific domain exception, to list the code to run in
that case. Using the ExceptionMappers, the code for a specific domain
exception is listed exactly once, in the ExceptionMapper for that one
class...
It is true that using ExceptionMappers things are more decentralized, and
people have to know JAX-RS/Jersey ... But as to the second - if they don't,
maybe they shouldn't be maintaining those HTTP classes?
Moises
On Mon, Feb 22, 2010 at 11:44 AM, Chris Carrier <ctcarrier_at_gmail.com> wrote:
> 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.
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>