users@jersey.java.net

Re: [Jersey] Idea for new contribution -- a pattern for handling HTTP errors as Java exceptions?

From: Julian Reschke <julian.reschke_at_gmx.de>
Date: Mon, 27 Oct 2008 14:49:32 +0100

Craig McClanahan wrote:
> Julio Faerman wrote:
>> Very intersting, something like that would be really helpful.
>> I just question the use of exception when there are multiple errors.
>> For example if i have 5 unparseable fields or 10 invalid records in a
>> batch. To handle this properly with exceptions, i think it would
>> require a weird "CompositeException".
> In all cases, I'm thinking that the entity body could contain more than
> one "message" element (one corresponding to each error). However,
> instead of needing a composite exception for this, my
> ValidationException explicitly allows you (the server code) to specify
> any number of individual messages ... each of them optionally tagged to
> a "field name". So you can still do the whole thing, at least for
> validation errors, with a single exception.
>
> If we need composites, it could probably be modelled that way -- I just
> haven't run into any use cases in our server code yet where we needed
> that. But I haven't tried doing batch type processing where there are
> multiple independent transactions in a single request. Maybe a
> multipart response could deal with that?

...without having read the whole thread...: keep in mind that there are
already servers out there putting additional information into the
response body in a *standardized* way, see
<http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.8.7>.

In one of my previous projects, we used that successfully to map "most"
of the errors that could occur to meaningful Java exceptions.

BR, Julian