Hello!


I was wondering how to best handle a case with functions that I would
like to collect several exceptions from. Is there an existing standard
way to solve this?

I was thinking of using the composite pattern for this allowing to throw
"a tree of exceptions" with the option to flatten it for display later.
How far off does that sound to you?



Sebastian

On 02/26/2010 07:11 PM, Sebastian Pipping wrote:
> Hello!
>
>
> I was wondering how to best handle a case with functions that I would
> like to collect several exceptions from. Is there an existing standard
> way to solve this?
>
> I was thinking of using the composite pattern for this allowing to throw
> "a tree of exceptions" with the option to flatten it for display later.
> How far off does that sound to you?

Do you have an example case where you want to use this? Is this a
common practice? Maybe other approaches are better?
--
Thanks,
Zac

On 02/27/10 04:20, Zac Medico wrote:
> Do you have an example case where you want to use this?

Multiple defects in metadata.xml are such a case.
At some point all the exceptions will have to collected, e.g. two
invalid herds are mentioned. In that case a single exception with a
list of invalid herds may suffice but it gets worse when combining
errors of slightly different types.


> Is this a
> common practice? Maybe other approaches are better?

No idea.



Sebastian

On Sat, Feb 27, 2010 at 05:02:18AM +0100, Sebastian Pipping wrote:
> On 02/27/10 04:20, Zac Medico wrote:
> > Do you have an example case where you want to use this?
>
> Multiple defects in metadata.xml are such a case.
> At some point all the exceptions will have to collected, e.g. two
> invalid herds are mentioned. In that case a single exception with a
> list of invalid herds may suffice but it gets worse when combining
> errors of slightly different types.

I'd suggest looking at pchecks design instead of trying to do
composite exceptions- essentially pass in a reporter that is invoked
w/ the failure/'exception' instead passed in.

Doing what you're suggesting (catching all exceptions at the top and
trying sum them essentially) results in screwy code flow in the
specific check- consider a check that can flag multiple issues.
Chucking an exception means you get the first warning spotted (and
just that).

Do the reporter/observer/tweaked visitor approach, you get all of the
issues, and it's left to the reporter to decide what to output (and
how to format it).

Also makes it a helluva lot easier to serialize the results into
pickles, or go parallel (multiple processes running, the reporter
in the subprocess just serializes the issue to a central process that
then amalgamates the results).

~harring

On 02/26/2010 08:27 PM, Brian Harring wrote:
> On Sat, Feb 27, 2010 at 05:02:18AM +0100, Sebastian Pipping wrote:
>> On 02/27/10 04:20, Zac Medico wrote:
>>> Do you have an example case where you want to use this?
>>
>> Multiple defects in metadata.xml are such a case.
>> At some point all the exceptions will have to collected, e.g. two
>> invalid herds are mentioned. In that case a single exception with a
>> list of invalid herds may suffice but it gets worse when combining
>> errors of slightly different types.
>
> I'd suggest looking at pchecks design instead of trying to do
> composite exceptions- essentially pass in a reporter that is invoked
> w/ the failure/'exception' instead passed in.
>
> Doing what you're suggesting (catching all exceptions at the top and
> trying sum them essentially) results in screwy code flow in the
> specific check- consider a check that can flag multiple issues.
> Chucking an exception means you get the first warning spotted (and
> just that).
>
> Do the reporter/observer/tweaked visitor approach, you get all of the
> issues, and it's left to the reporter to decide what to output (and
> how to format it).

Good idea. It's similar to the os.walk() 'onerror' argument.
--
Thanks,
Zac

Good idea, thank you!



Sebastian