Re: RFC: finish_command_continuation and errors

[Pedro Alves <pedro@codesourcery.com>]

On Thursday 18 March 2010 17:59:02, Tom Tromey wrote:
> Pedro> For the record, can you show us which error was that?
> 
> In this case it was:
> 
> Value returned is $9 = warning: RTTI symbol not found for class 'java::lang::String'
> Cannot access memory at address 0x0

Thanks.  Looks strange that GDB found something missing, and still
tried to use address 0x0 though.  Is the 0 GDB working with a NULL
type somewhere?  Or is that unrelated?

> Pedro> This probably also fixes frontends: the normal_stop observers
> Pedro> notification call just a bit below was skipped too, which means
> Pedro> the MI *stopped notification must have gone missing; a frontend
> Pedro> was being left with no idea the thread had stopped.  Could you
> Pedro> check with your test, but running with -i=mi, that
> Pedro> mi_on_normal_stop also isn't throwing an exception too in your
> Pedro> case?  I suspect not, but just in case.  You can issue the normal
> Pedro> CLI commands while in -i=mi to test this.
> 
> I tried this and it worked fine after my patch.  From what I can see,
> mi_on_normal_stop doesn't try to print the return value.

Yes.  Thanks.  I didn't know what exactly was failing before -- I
was wondering if frame printing would also be failing.

> It seems to me that, abstractly, observers should not be allowed to
> throw exceptions.  Perhaps the observer machinery itself ought to catch
> them.  My reasoning is that letting an observer throw an exception will
> make the observer mechanism apparently unreliable: a given observer
> might or might not be called, depending on whether some earlier observer
> encountered an error.

Yes, agreed in general.  I think some classes of errors still
need escaping though, like internal errors, and Quits.

-- 
Pedro Alves