1 |
On Sat, Feb 27, 2010 at 05:02:18AM +0100, Sebastian Pipping wrote: |
2 |
> On 02/27/10 04:20, Zac Medico wrote: |
3 |
> > Do you have an example case where you want to use this? |
4 |
> |
5 |
> Multiple defects in metadata.xml are such a case. |
6 |
> At some point all the exceptions will have to collected, e.g. two |
7 |
> invalid herds are mentioned. In that case a single exception with a |
8 |
> list of invalid herds may suffice but it gets worse when combining |
9 |
> errors of slightly different types. |
10 |
|
11 |
I'd suggest looking at pchecks design instead of trying to do |
12 |
composite exceptions- essentially pass in a reporter that is invoked |
13 |
w/ the failure/'exception' instead passed in. |
14 |
|
15 |
Doing what you're suggesting (catching all exceptions at the top and |
16 |
trying sum them essentially) results in screwy code flow in the |
17 |
specific check- consider a check that can flag multiple issues. |
18 |
Chucking an exception means you get the first warning spotted (and |
19 |
just that). |
20 |
|
21 |
Do the reporter/observer/tweaked visitor approach, you get all of the |
22 |
issues, and it's left to the reporter to decide what to output (and |
23 |
how to format it). |
24 |
|
25 |
Also makes it a helluva lot easier to serialize the results into |
26 |
pickles, or go parallel (multiple processes running, the reporter |
27 |
in the subprocess just serializes the issue to a central process that |
28 |
then amalgamates the results). |
29 |
|
30 |
~harring |