This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [python] [patch] PR python/13331


On Oct 24, 2011, at 11:51 AM, Phil Muldoon wrote:

> Paul Koning <paulkoning@comcast.net> writes:
> 
>>> ... On the other hand, there is
>> missing cleanup: any objects added to the tuple before the failing
>> call need to have a DECREF done on them.
> 
> I'm not sure what you mean by this.  If result fails, the args check in
> the calling function will fail, the exception converted to a gdb_error,
> the exception bits cleared and the call will fail. The loop will not be
> executed.  It is also my understanding that PyTuple_SetItem steals a
> reference to the object being added.  In this case, there is only one
> reference to the object, so the logic here works.  When the tuple is
> garbage collected, the reference count for each object will
> automatically be decremented and therefore garbage collected too.

Yes, I got confused.  Sorry.

> ...
>> 
>> That should just be a cleanup and return NULL -- the
>> PyObject_GetAttrString has set the exception.
> 
> Well yes and no, it is seemly expedient here to short-circuit the
> process and convert it to a gdb error directly.  The error is more
> informative than the error from GetAttrString -- that is there is no
> "invoke" function.  This is something we (as in GDB), want to enforce in
> our API

I see what you mean, that makes sense.  Keep the original exception unless there is a reason to replace it -- for example to add more detail or make it more descriptive.

	paul


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]