[patch] [python] Use TRY_CATCH in some functions.
Phil Muldoon
pmuldoon@redhat.com
Thu Oct 20 13:03:00 GMT 2011
Tom Tromey <tromey@redhat.com> writes:
> Phil> @@ -624,20 +625,31 @@ typy_lookup_type (struct demangle_component *demangled,
> [...]
>
> Phil> + if (except.reason < 0)
> Phil> + {
> Phil> + PyErr_Format (except.reason == RETURN_QUIT
> Phil> + ? PyExc_KeyboardInterrupt : PyExc_RuntimeError,
> Phil> + "%s", except.message);
> Phil> + return NULL;
>
> Why not GDB_PY_HANDLE_EXCEPTION here?
> (And also fix up typy_lookup_typename to do the same.)
Because typy_lookup_typename and typy_lookup_type are helper functions
that return struct type, while GDB_PY_HANDLE_EXCEPTION returns a
PyObject (from gdbpy_convert_exception). Should we have a macro that
builds an exception without returning one? We should, I think. But I was not
going to do that in this patch context.
> Phil> @@ -990,8 +1002,16 @@ typy_richcompare (PyObject *self, PyObject *other, int op)
> [...]
> Phil> + {
> Phil> + bcache_xfree (cache);
> Phil> + VEC_free (type_equality_entry_d, worklist);
> Phil> + GDB_PY_HANDLE_EXCEPTION (except);
>
> I think the freeing should be hoisted above the exception check, to
> consolidate the code. With the current patch the code is duplicated on
> both branches.
I amended the logic to look like this:
@@ -1007,11 +1007,13 @@
{
result = check_types_worklist (&worklist, cache);
}
- if (except.reason < 0)
- result = Py_NE;
-
+ /* check_types_worklist calls several nested Python helper
+ functions, some of which can raise a GDB Exception, so we
+ just check and convert here. If there is a GDB exception, a
+ comparison is not capable (or trusted), so exit. */
bcache_xfree (cache);
VEC_free (type_equality_entry_d, worklist);
+ GDB_PY_HANDLE_EXCEPTION (except);
}
if (op == result)
Cheers,
Phil
More information about the Gdb-patches
mailing list