On Jul 2, 2009, at 10:30 AM, Dag Sverre Seljebotn wrote: > I'm taking this to the list... > > Kurt Smith wrote: >> Dag, >> >> When an exception or an error needs to be generated, what are the >> guidelines? It seems Errors.error() is normally called, although an >> exception isn't raised at this point, & compilation continues -- the >> errors are collected and reported at the end of everything then. A >> few other times I see a 'raise CompileError' or 'raise InternalError' >> instead. When should these be raised instead of just calling >> Errors.error()? I seem to recall that InternalError is an error with >> the compiler itself, while CompileError is raised when there's >> something wrong with the source. > > I wouldn't trust these rules to be followed everywhere, but: > > In general, exceptions should not be raised, but compilation go on > while > "ignoring" what caused the error. > > In e.g. declaration analysis, the right procedure is to call > Errors.error and set "self.type" to PyrexTypes.error_type (or > similar). > Then code which need to use the type should check if it is error_type > and if so, return early (i.e. "ignore" this part of the tree; > compilation will be aborted later anyway). > > Some places though an exception may still be the right thing -- if > it is > trapped further out in the node tree. I.e. to recover from an error > in a > subnode it might be proper to use exception to go back to a parent > node, > then that parent node is skipped and its sibling processed next.
I can't think of any cases, but this could be acceptable as well. Ideally any such errors thrown would be caught before hitting the top level. In general, my attitude is to raise an exception when you get to a point that something has gone irrevocably wrong. If this is due to bad user code, typically the right thing to do is use Errors.error and continue (perhaps skipping hte node, setting things like type to dummy variables. You can raise InternalError which will get ignored if errors were encountered at an earlier stage, but again, if you can continue it'd be better try and do so. > Also there's the problem that currently some error reporting is > done in > code generation. This should NOT be done for new code, as a long-term > goal is to have a stage in the pipeline where we say "everything is > parsed and is correct; from now on, pipeline transforms can assume no > errors have occurred". +1 >> Sometimes when simply calling Errors.error(), the rest of the code >> raises another exeption, like AttributeError because things are in an >> inconsistent state after the error() call. It would be nice to >> ensure >> that everything stops at the error() call, but then cython won't >> continue past the first error then which makes testing a pain. We could catch everything and ignore it if Errors.error() had been previously, but even though it makes developing a bit more difficult (in the short run, probably easier in the long run), and it is very useful when writing Cython code to have it go as far as possible before giving up so I'm -1 on that idea. (At the other extreme, imagine the pain writing code if the compiler always stopped at the first parse error it hit. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
