mark florisson, 27.01.2012 17:30: > On 27 January 2012 16:22, mark florisson <markflorisso...@gmail.com> wrote: >> On 27 January 2012 15:47, Simon King <simon.k...@uni-jena.de> wrote: >>> Hi all, >>> >>> I am still *very* frustrated about the fact that Cython does not tell >>> where the error occurs. Since about one week, I am adding lots and >>> lots of lines into Sage that write a log into some file, so that I get >>> at least some idea where the error occurs. But still: Even these >>> extensive logs do not provide a hint on what exactly is happening. >>> >>> How can I patch Cython such that some more information on the location >>> of the error is printed? I unpacked Sage's Cython spkg, and did "grep - >>> R ignored .", but the code lines containing the word "ignored" did not >>> seem to be the lines that are responsible for printing the warning >>> message >>> Exception AttributeError: 'PolynomialRing_field_with_category' >>> object has no attribute '_modulus' in ignored >>> >>> Can you point me to the file in Sage's Cython spkg which is >>> responsible for printing the warning? >>> >>> Best regards, >>> Simon >> >> These messages are written by PyErr_WriteUnraisable, which is a >> CPython C API function that writes unraisable exceptions. There are >> typically two reasons for unraisable exceptions: >> >> 1) as Robert mentioned, a function that does not allow propagation >> of exceptions, e.g. >> >> cdef int func(): >> raise Exception >> >> Here there is no way to propagate the raised exception, so >> instead one should write something like >> >> cdef int func() except -1: ... >> >> Alternatively one may use 'except *' in case there is no error >> indicator and Cython should always check, or "except ? -1" which means >> "-1 may or may not indicate an error". >> >> 2) in deallocators or finalizers (e.g. __dealloc__ or __del__) >> >> For functions the right thing is to add an except clause, for >> finalizers and destructors one could use the traceback module, e.g. >> >> try: >> ... >> except: >> traceback.print_exc() >> >> If this all still doesn't help, try setting a (deferred) breakpoint on >> __Pyx_WriteUnraisable or PyErr_WriteUnraisable. > > Actually, I don't see why the default is to write unraisable > exceptions. Instead Cython could detect that exceptions may propagate > and have callers do the check (i.e. make it implicitly "except *"). > Was this not implemented because Cython only knows whether functions > may propagate exceptions at code generation time by looking at the > presence of an error label? > Maybe it could keep code insertion points around for every call to > such a potential function and if the function uses the error label > have the caller perform the check? Although I do forsee problems for > external such functions... maybe Cython could have it's own > threadstate regardless of the GIL which would indicate whether an > error has occurred? e.g. CyErr_Occurred()?
Yep, those are the kind of reasons why writing unraisable exceptions is the default. Stefan _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
