Re: RFC: finish_command_continuation and errors

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

>> This can happen if gdb calls error while printing the return value.

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

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.

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.

Tom