C extension module doesn't throw exception after setting error indicator through PyErr_SetString()

rahul rahul03535 at gmail.com
Thu Aug 2 05:50:21 EDT 2012


When I use same code base for Python 3.x, then behavior is different. In this when I return false then also it throws exception but only when any other statement get executed after this 

like below code:
 ...
 ...
   b = None
   try:
     a = testModule.check(None)
   except:
     b = sys.exc_info()
then code execution doesn't come to except block.
But when I add one statement after calling check function then code execution goes into except block. 

 ...
 ...
 b = None
 try:
   a = testModule.check(None)
   print( a )
 except:
   b = sys.exc_info()


On Thursday, 2 August 2012 15:07:08 UTC+5:30, Tim Golden  wrote:
> On 02/08/2012 10:21, rahul wrote:
> 
> > 
> 
> > Hi TJG,
> 
> > 
> 
> > The above link also doesn't strictly said that return value should be
> 
> > NULL only, it only said that usually NULL pointer used. No where I
> 
> > saw that it is nessasory t
> 
> > 
> 
> > At http://docs.python.org/c-api/exceptions.html. it is written that
> 
> > "Most functions also return an error indicator, usually NULL if they
> 
> > are supposed to return a pointer, or -1 if they return an integer
> 
> > (exception: the PyArg_*() functions return 1 for success and 0 for
> 
> > failure)." this also told that usually NULL is used but we can change
> 
> > the return error indicator to any value. As like PyArg_*() used 0 for
> 
> > error value.
> 
> 
> 
> The docs you quote are very slightly confusing because they're combining
> 
> the standard practice (return NULL), the uncommon alternative (return
> 
> -1) and a few special cases present in the core functions.
> 
> 
> 
> In short, any function you expose in an extension module will be
> 
> returning a PyObject* and should return NULL if it is setting or
> 
> cascading an exception.
> 
> 
> 
> I'm not convinced that the docs need altering here: this is the first
> 
> time I've come across anyone who was confused. But if you think some
> 
> different wording might help, feel free to propose something.
> 
> 
> 
> TJG



More information about the Python-list mailing list