I am thinking on the programmer trying to indicate the errors. If he has
more than one error, or is still processing and accumulating the errors, he
can not simply throw the exception, as the method would exit. Unless he
accumulates the errors in a exception and throw it in the end of the method,
am i correct ? perhaps i am missing something...
About the multipart response, i think it would be easy for a java client to
iterate on it, but i don't know about AJAX consumers, for example.
On Fri, Oct 24, 2008 at 3:23 PM, Craig McClanahan
<Craig.McClanahan_at_sun.com>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?
>
>
> Craig
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>