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: Tue, 31 Aug 2010 19:42:44 +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> <4C6059CE.2050300@redhat.com>
On 09/08/10 20:41, Phil Muldoon wrote:
> 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
Ping