Re: [python] [patch] PR 12174 (preserve gdb.GdbError behaviour)

[Phil Muldoon <pmuldoon at redhat dot com>]

Tom Tromey <tromey@redhat.com> writes:

>>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:
>
> Phil> In the case of gdb.execute, gdb.GdbErrors were being converted to
> Phil> GDB errors and back again to a Runtime Exception.
>
> I suppose the scenario is a command written in Python that uses
> gdb.execute("something"), where "something" is itself written in Python.
> Then if "something" raises GdbError, gdb.execute winds up calling error,
> which translates to a RuntimeException?
>
> It seems to me that what we really want is some unification between the
> Python and GDB exception mechanisms.  That is, a way to preserve the
> exception across the GDB/Python boundary.
>
> This would provide some benefits; e.g., the current patch loses subtype
> information from the GdbError.

At this point I'm not sure why this subtype information is relevant.
It's not been handled, so it will either be printed out by GDB or
Python.  Regardless, when the stack trace is printed the exception
is gone (and no sub-type information is contained there, that I know
of). 


> I haven't really thought through the implications of this.  Maybe there
> are problems lurking.


Mark had a different approach in the bug, there is a patch included.
That is something that preserves sub-type (see above) but it adds a
special handling case for these types of exception.  From my point of
view that is not preferable.  But if works for you and Mark I'll
implement it.

> Phil> I was unsure if I should call print_exception in gdb.execute or whether
> Phil> just to let the Python exception propagate.
>
> I think it has to propagate.  If it was ok to print the exception here,
> then we wouldn't need this patch at all.

This part just merely replicates what the user wants, a gdb.GdbError
that just prints out a message without a trace-back.  The use case of
running a script in one way producing one result for exceptions, and
another way producing another was what I wanted to avoid.  That being
said, I do not hold strong views on this.

What's the way forward here?

Cheers,

Phil