Re: [gnet] Re: GNet library (2.0.5)

[Tim Müller <tim-mailinglists zen co uk>]

On Saturday 20 November 2004 11:12, Wolfgang Wieser wrote:

> > > - PLEASE: We need better error reporting.
> > >
> > >   One outstanding feature which we had long time under Unix and Linux
> > >   (and still have on the command line) is fine-grained error reporting.
> >
> > Maybe - How do you want to do it?  Adding a gnet_errno is possible.
> > Adding string support is harder because then GNet would need to support
> > string translations.
>
> I'd suggest to add it much like the other error reporting in glib:
>
> Functions that can fail take a return location for a GError as their last
> argument. For example (snip)
>
> People who just want to go on reporting "could not..." to the user can pass
> NULL for the error.
>
> For callbacks lets simply pass an GError * as well.

One problem with GError * is that it only exists in GLib-2.0, but not in 
GLib-1.2. 

Personally, I think it's time for GNet to drop support for GLib-1.2 
altogether, and to start making more extensive use of all the GLib-2.0 
goodies. At some point we will need to start supporting non-ASCII domain 
names (RFC3490), and the GLib-2.x unicode stuff will come in handy for that.

> > I think "Failed to connect" is fine for a user message.  Most users
> > have no idea what the difference is between no route to host /
> > connection timed out / etc.
>
> I object here. Since programs I write are not for the "average stupid user"
> but for people who need to know more. And as for what I plan (some
> network distribution of calculations), connection refused, timeout and
> "no route to host" really make a difference and show you if the client
> died, the box went down or the network is broken.

While it is true that the average user doesn't know the difference between 'no 
route to host', 'connection timed out', and so on, it is still very important 
to make this more detailed information available to the application 
programmer, for two reasons:

 * if stuff doesn't work, users go for support to people who probably
    know what these messages mean. We will make life much easier for
    everybody involved if we make all of this information available. We
    can always give out 'Failed to connect (more detail)' or so.

 * the application programmer might want to take different fall-back actions
    depending on the problem (I can't think of a good scenario right now, but
    then I haven't had my morning coffee yet; I'm sure good ones exist).

Cheers
 -Tim