Robert Bradshaw wrote: > On Fri, 15 Aug 2008, Greg Ewing wrote: > >> Dag Sverre Seljebotn wrote: >> >>> So I propose this change: There is a cutoff in the pipeline at which >>> stage errors are reported (and if any, processing stops). >> >> That sounds reasonable. You could even go further and have >> a cutoff after every stage of the pipeline, so that any >> stage can assume it has valid data from the previous stage. > > Often it is useful to maximimize the number of errors caught in a single > invocation of the compiler. One thing I hate doing is (run the compiler, > fix the only reported error) x 10. > >> A refinement would be to have "fatal" and "non-fatal" >> errors, where fatal errors terminate compilation at >> the end of the current pipeline stage. > > This sounds like a very good idea. Non-fatal errors would result in a > valid tree that could be carried on to the next stage, but invalid > compilation. > > It might be to hackish, but we could also run each stage in a try-catch, > and if it catches any Exceptions after a "non-fatal" error it silently > ignores them.
I already did this :-) sort of, but non-fatal error might very well require that processing continues within the transform. The current system is that transforms can raise a CompileError if processing cannot continue, or call self.context.nonfatal_error(CompileError(..)) if they just want to report an error and let the execution thread move on. It seems too much to add yet another mechanism to abort just a single transform (you just use a try-except clause in __call__ to drop out of the transformation stack and report the error as nonfatal before returning). So I'll just add a pipeline step that checks the nonfatal error list and stops compilation if there were nonfatal errors (prior to code generation). One can drop out before this by raising a CompileError and let it go all the way up to the pipeline runner. I'm mostly asking here for what we do for the beta -- the kind of errors we report could also be considered a regression; so too large a change doesn't seem good, but obviously Cython shouldn't crash either. But it seems like we agree. Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
