This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] PR python/11407


On Friday 25 June 2010 20:25:10 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.

I'd guess it would be nice for a front end to get a hint that something
unusual happened in case it wants to have some kind of special handling
of such cases (like localizing the error message).

A separate field error="...", or perhaps value="<error reading variable: %s>"
as suggested with an additional field  iserror="1" would be easier to handle
than checking the "value" field for well-known strings, especially if such
content could be legal output in some cases, too.

[But take this with a grain of salt, I/we haven't used MI for data retrieval for a 
while now, so maybe there are already enough hints in the output nowadays.]

Andre'





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]