[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pykde
Subject:    [PyKDE] Re: Bug (or feature?) in sipParseArgs
From:       Phil Thompson <phil () river-bank ! demon ! co ! uk>
Date:       2002-06-27 15:32:49
[Download RAW message or body]

Donovan Rebbechi wrote:

> I noticed a curious feature in sipParseArgs recently-- sometimes, it
> leaves the error handler with a "dangling error" set when it returns false.
> Judging by the code in parsePass1(), and the idiomatic usage in generated code
> where several blocks are tried one after the other, this looks like a
> mistake.  It certainly resulted in some interesting and obscure bugs in
> my code ;-)
> 
> I took a look at the code (sip 3.2.4) and PyErr_Clear() is called at the
> top of the loop, but not before the exit of the function, which means that
> if the last loop iteration sets a python exception, the function exits in
> that state.
> 
> The fix that addresses this is to call PyErr_Clear() at the end of ParsePass1()


The behaviour is intentional. A call to sipParseArgs() can raise two 
sorts of exception.

The first describes why the parse failed, but would only be passed back 
to the application if it was the last parse in the sequence. 
sipParseArgs() isn't told if it is the last one, so it has to assume it 
might be and raise the exception.

The second describes some operational problem with converting the Python 
objects after a successful parse. These exceptions must be passed back 
to the application - these are "sticky" exceptions as far as 
sipParseArgs() is concerned. If it sees that a sticky exception has 
already been raised then automatically fails any future parse.

Phil

_______________________________________________
PyKDE mailing list    PyKDE@mats.gmd.de
http://mats.gmd.de/mailman/listinfo/pykde
[prev in list] [next in list] [prev in thread] [next in thread]