Robert Bradshaw wrote: > 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.
I think this misrepresents the issue. Currently error(...) and self.context.nonfatal_error(PostParseError(...)) does almost the EXACT SAME thing, especially no exception is raised. The difference is that the self.context indirection allows one to plug in a different error reciever for a transform in some situations. As transforms are otherwise completely isolated, I don't like breaking IoC for this one case. But it's not important. But either context.nonfatal_error should be removed, or all calls to "error" in transforms should be replaced with context.nonfatal_error. -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
