> > Actually there are currently two ways to catch an error in MI:
> >
> > 1) Using error () and catch_exception.
> >
> > 2) Using MI_CMD_ERROR and mi_error_message.
> >
> > The first gets caught in mi_execute_command and the error message is stored
> > in result.message. The second goes back to captured_mi_execute_command and
> > the error message is manually stored in mi_error_message.
> >
> > I think that only one method should be used and this should be the first
> > one.
>
> Once upon a time there were supposed to be more things using "libgdb"
> - these gdb_* wrapper functions. It didn't come to pass.
I thought the gdb_* wrapper function were just designed to catch exceptions.
Does your statement defeat the logic of my suggestion?
> For now can we do the minimal fix for this problem? I apologize I was
> never clear enough about what I meant when I said that, so here's a
> patch.
Yes. I can't believe now that I didn't consider this option.
> ...
> 2007-03-27 Daniel Jacobowitz <dan@codesourcery.com>
>
> * breakpoint.c (gdb_breakpoint_query): Really return an
> enum gdb_rc.
> (gdb_breakpoint): Likewise.
> * thread.c (do_captured_list_thread_ids): Likewise.
> (do_captured_thread_select): Likewise.
> * mi/mi-main.c (mi_cmd_thread_select): Expect an enum gdb_rc.
> (mi_cmd_thread_list_ids): Remove bogus initialization.
I think that the do_captured_* functions should have return type enum gdb_rc
not int.
More generally though, re my patch, does make_cleaunp work on
deprecated_set_gdb_event_hooks? Do you think it's a good idea to distinguish
between user errors, e.g, "No stack." and front end errors, e.g,
"-var-delete: Usage: [-c] EXPRESSION."?