On 18 Feb 2015, at 4:25 pm, Paul Hoadley <[email protected]> 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 protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
