On Mar 24, 2009, at 11:20 AM, Dag Sverre Seljebotn wrote:

> Kurt Smith wrote:
>> Here's the addition of a test case.
>>
>> I added a visit_ReturnStatNode in PostParse (not in the patch below),
>> but it seems there is some issue with error handling.  If I raise a
>> PostParseError, everything is fine and the compiler stops there.  But
>> when there are multiple tests in the test case (see below) the later
>> errors (3:4 and 6:4) aren't tested.  It seems that the best route is
>> to call the error(pos, message) function and have it record the
>> errors; this works for other stages in the pipeline
>> (AnalyseDeclarationsTransform, e.g.) but fails at the PostParse stage
>> (the compiler barfs).
>
> Indeed, this is one of the unclean things (of many) in Cython where
> different people have used different conventions. Myself I would  
> like to
> never call Errors.error from transforms, because then you get full
> Inversion of Control and can much more easily unit-test.
>
> I suppose we should just agree on something (in fact we may have  
> agreed
> on using Errors.error, I can't remember). Stefan, Robert?

One of my pet peeves is when I'm compiling something, and it gives me  
a single error, which i then fix, and it gives me one more, etc. This  
is why, when it's possible to continue, I think it's better to use  
Errors.error.

Surprising it doesn't work though--was this some special code you put  
in Dag?

> For now, try my preferred IoC way;
>
> self.context.nonfatal_error(PostParseError(...)).
>
> Also, proceed to "return None" which will delete the node from the  
> tree
> before further processing.

You make a good point about CVarDefNode, but I think this case (and  
most statements) are much simpler.

- Robert


_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to