Marc Hadley wrote:
> What component/class does your @ExceptionHandler hand the job of
> mapping to ? IOW do you envision a local (vs global) equivalent of an
> ExceptionMapper ? If so wouldn't that also need to be listed in the
> annotation so the framework knows which one to use ?
I am not sure how and whereto it would map (only having mocked up the
feature), but I would expect the global ones to be last resort and
default (just like Apache's error pages are). Class-wide ones would take
precedence over global ones and method declared ones would take
precedence over everything else.
> I've found global exception mappers (implements ExceptionMapper) very useful in my work but that is a fairly uniform API with a small set of throwables. I can see it might be useful to be able to scope exception mappers such that you can select amongst multiple different mappers for the same exception depending on context - is that the kind of thing you have in mind ?
Exactly! For instance, a part of my API uses the path as a fairly
sophisticated query language for composing charts ( Chart -> Plot ->
Meter -> Registration + various meta data). I would like to be able to
report a 400 (Dude you ain't making sense) but in this response also
include a viewable (if consumer accepts html) which lets the browser
render an editor and/or debugger. I just see it as a flexible annotation
based ExceptionMapper which is scoped and picked up on-site rather than
globally scoped on some arbitrary provider path.
/Casper