Folks,
I guess I found the answer in the source: ExceptionMapperFactory.find()
locates all the exception mappers that are capable of translating the
exception and then returns the one that is closest in terms of nodes in
the class hierarchy.
So FooException in my case will properly get translated by the
FooExceptionMapper because its distance to FooException is less than
that of the mapper for RuntimeException or the mapper for Exception (0
versus 1 versus 2).
That also explains why it never failed after refactoring, but I had to
be sure.
cheers,
Erik
Erik van Zijst wrote:
> Hi folks,
>
> I'm refactoring to using ExceptionMapper to get rid of the
> exception-to-return-code translations in my services, but I'm unsure if
> I'll still be able to tanslate exception subclasses into specific errors.
>
> For example, I want FooException (which extends RuntimeException) to be
> mapped to 409 (Conflict), while I want any other RuntimeExceptions that
> pop out, to be translated into a 400 (Bad Request) and finally, I want
> all other (checked) exceptions to generate a normal 500, but still
> control the contents of the body of the response by using a custom mapper.
>
> In my existing code, I just organize the catch clauses so they first
> catch FooException, then RuntimeException, followed by Exception.
>
> However, when using ExceptionMappers, I'm afraid that when my service
> throws a FooException, it may get caught by the RuntimeExceptionMapper
> and translated to 400 instead of 409.
>
> Is there a way to ensure every exception gets caught by the appropriate
> mapper?
>
> cheers,
> Erik
>