On 15 Jan 2015, at 4:53 am, Chuck Hill <
email@hidden> wrote:
IIRC, it should work like the first example, but it is possible that some code is creating the thrown exception incorrectly. The last code example is probably safe.
I'm still not quite there with this—I'm getting exceptions "dropped" in practice. (I know they're being created, but by the time things get back to the view layer, I'm seeing fewer validation error messages than expected.) I managed to dig up a thread about as old as the one previously quoted:
I think this is very close to what I want, but, and I can hardly believe I'm typing this... is there a bug in either or both of ValidationException.aggregateExceptionWithExceptions() or ValidationException.additionalExceptions()? If I call aggregateExceptionWithExceptions() on an array with two ValidationExceptions v1 and v2 where both v1.additionalExceptions() and v2.additionalExceptions() returns null (that is, there's no nesting), it returns what I'd expect, which is basically v1 with v1.additionalExceptions() returning v2. That's great. Call that ag1.
If I put ag1 and a third, non-nested ValidationException v3 in an array together, and call aggregateExceptionWithExceptions() on that array, the result is indistinguishable from ag1 itself. I just get v2 nested in v1, and v3 is apparently ignored. However, calling ag2.userInfo().valueForKey(ValidationException.AdditionalExceptionsKey) (which is deprecated in two places—userInfo() and AdditionalExceptionsKey), I can see v3 in the result!
I can provide code if someone wants to see it, but I thought it more likely that this is a known problem, or my expectations are wrong, and someone might just be able to set me straight. Any thoughts on this Chuck?