Re: Adding error reporting to GtkFileChooser

[Owen Taylor <otaylor redhat com>]

On Wed, 2004-03-03 at 13:25, Morten Welinder wrote:
> > Boolean returns can be added at any time without breaking  
> > compatibility
> 
> That's technically an API change, but not an ABI change.  If
> someone was to use function pointers to any of these it would
> not match.
> 
> > Why an application would get an error calling one
> > of these functions
> 
> For lots of reasons stat() can fail:
> 
> 1. Permission problems.
> 2. File not there anymore.
> 3. File too big.  [Bug 136082.]
> 4. Causes due to NFS or other remote file systems.

Sure, errors can occur, but the question is what is the
app going to do if the error fails?

If something has an error return in the API, then you are
saying that the caller must handle it.

(Especially if a language binding turns errors into exceptions!;
then you need to write:

 eval {
   chooser->set_current_folder ("/new/directory");
 } 

or if that folder is no longer there, then your app exits;
I'm not convinced that GError => exception is a great idea,
unless the language compile-time requires all exceptions to be 
caught or rethrown.)

> Right now, some functions like gtk_file_chooser_default_select_path display
> an error dialog(!) when this happens.  (Bug 136024.)  That's absurd for
> an API call.

I agree that popping up a dialog is wrong here. The question
though we always have to answer is "can the app do better than
what GtkFileChooserDialog should (like ignore)".

Regards,
					Owen