Re: Adding error reporting to GtkFileChooser

On Wed, 2004-03-03 at 17:45, Owen Taylor wrote: 
> On Tue, 2004-03-02 at 15:48, Federico Mena Quintero wrote:
> > Some functions in GtkFileChooser don't report errors back to the caller:
> > 
> > 	gtk_file_chooser_set_filename
> > 	gtk_file_chooser_select_filename
> > 	gtk_file_chooser_unselect_filename *
> > 	gtk_file_chooser_set_current_folder
> > 	gtk_file_chooser_set_uri
> > 	gtk_file_chooser_select_uri
> > 	gtk_file_chooser_unselect_uri *
> > 	gtk_file_chooser_set_current_folder_uri
> > 	gtk_file_chooser_set_current_name **
> > 
> > These all return void and take a string argument.  Are we truly
> > API-frozen, or should I make them return gboolean and take in a 
> > GError **?
> 
> We are hard API/ABI frozen at this point, but this is by policy, not
> by necessity, so if we need to make an exception we can make an
> exception, with the downsides:
> 
>  - We will cause people to re-roll GNOME tarballs that use
>    these functions.
>  - We cause language binding authors to have to re-rev
>  - We could possibly (though probably not here) regress with 
>    these API changes and be in worse trouble
>  - We look lame
> 
> Looking lame should never be a criterion for whether or not to
> do something, so if the benefits outway the first downsides,
> we should make the change. (So, to make the change, I'd like
> to get release team and bindings authors sign off on it first.)

If these functions are likely to fail, and if the application really
needs to know about that, then

1 (of a usually necessary 2) release-team approval.
1 (of a possible 3) binding maintainer approval.

-- 
Murray Cumming
www.murrayc.com
[email protected]