Re: Aggregating ValidationExceptions in validateForSave()
Re: Aggregating ValidationExceptions in validateForSave()
- Subject: Re: Aggregating ValidationExceptions in validateForSave()
- From: Paul Hoadley <email@hidden>
- Date: Thu, 19 Feb 2015 08:57:15 +1030
On 18 Feb 2015, at 4:25 pm, Paul Hoadley <email@hidden> wrote:
> 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?
I think I've got it. I may have neglected to mention that all the exceptions I'm talking about are ERXValidationExceptions, created by ERXValidationFactory.createException(). It turns out that ValidationException.aggregateExceptionWithExceptions() doesn't play nicely with ERXValidationExceptions because of the way the two classes handle their additionalExceptions: the former sticks them in its userInfo dictionary, the latter in an array. So aggregateExceptionWithExceptions() does everything right, but then calling the overridden additionalExceptions() method is essentially looking in the wrong place. (ERXValidationException.additionalExceptions() will look in the superclass's userInfo dictionary, but only if it doesn't have any additionalExceptions of its own. I am somehow creating a situation where they're mixed between the two places.)
I should be able to rig up a solution, but I couldn't possibly be the first person to stumble over this—is there a better way to mix and match exception types when aggregating them like this? Should I be using a different method to do the aggregation?
--
Paul Hoadley
http://logicsquad.net/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden