Re: [RFC] -thread-info new command

[Nick Roberts <nickrob@snap.net.nz>]

 > > 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."?

-- 
Nick                                           http://www.inet.net.nz/~nickrob