Re: [patch] [python] Use TRY_CATCH in some functions.

Phil Muldoon
2011-10-20T12:58:33Z

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