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.

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".


> 
> 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.
> 
> I'm almost done with the MemoryviewType initialization -- just putting
> in the (many) testcases right now & doing some sanity checks.  I'll
> put it up for review tomorrow.
> 
> Kurt


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

Reply via email to