This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] PR python/11407
- From: Phil Muldoon <pmuldoon at redhat dot com>
- To: tromey at redhat dot com
- Cc: gdb-patches at sourceware dot org, vladimir at codesourcery dot com
- Date: Mon, 09 Aug 2010 20:41:02 +0100
- Subject: Re: [patch] PR python/11407
- References: <4C23426F.4020502@redhat.com> <m3aaqk8foj.fsf@fleche.redhat.com> <4C23D5CB.5040702@redhat.com> <m3y6e33r7d.fsf@fleche.redhat.com> <4C251D93.6020909@redhat.com> <4C34B319.2030901@redhat.com>
On 07/07/10 18:02, Phil Muldoon wrote:
> On 25/06/10 22:20, Phil Muldoon wrote:
>> On 06/25/2010 07:25 PM, Tom Tromey wrote:
>>>>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:
>>>
>>> Phil> I'm not sure what to do in this case. There seems to be no direct
>>> Phil> equivalent of converting an exception to error output on a stream in MI
>>> Phil> (or any cases of TRY ... exception handlers). There are many cases of
>>> Phil> MI raising an error() though, so I thought it appropriate in our case
>>> Phil> to raise a warning() instead. Because of the peculiarities of the MI
>>> Phil> cases I just report a warning generically and move on. This is not
>>> Phil> totally ideal, but it does allow the error/warning preamble followed
>>> Phil> by the actual locals information.
>>>
>>> I'm not convinced a warning is the best thing.
>>>
>>> Why not catch the exception and print the text of it as the variable's
>>> value? Something like <error reading variable: %s>
>>> I think this will work ok with existing front ends.
>>
>> Here is a patch that does that.
>>
>> What do you think?
>>
>> Cheers,
>>
>> Phil
>>
>
> Tom >> I am curious to hear what Volodya wants.
>
>
> Adding Vladimir Prus to the CC list.
>
Ping