Re: [RFC] -thread-info new command

[Denis PILAT <denis.pilat@st.com>]

Nick Roberts wrote:
>  > > 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."?
>
>   

Is there anything new about that ?
Should I re-propose a patch for -thread-info ?
-- 
Denis