Re: [Vala] Wrapping Errors

[Phil Housley <undeconstructed gmail com>]

2009/8/22 Jan Hudec <bulb ucw cz>:
> On Thu, Aug 20, 2009 at 22:09:21 -0400, Yu Feng wrote:
> > GError doesn't support error wrapping as Java does. Is GLib is purposely
> > avoiding it?
> > If not, it will become a useful feature as the number of libraries that
> > uses GError grows, as the feature has already been proved useful in
> > Java, (indicated in this article):
> >
> > http://tutorials.jenkov.com/java-exception-handling/exception-wrapping.html
>
> Actually, in my opinion that article nicely explains, why you do *not* need
> to have the original error information there.

In Java, this feature is actually used a lot, and can be incredibly
helpful.  A common example goes:

void dbaccess() {
  throw new DatabaseError();
}

void sometransaction() throws FailedToCompleteError {
  if (bad data) throw new FailedToCompleteError();
  try {
    dbaccess();
  } catch(DatabaseError e) {
    // this is still a failure to complete
    throw new FailedToCompleteError(e);
  }
}

void abusinessfunction() throws FailedToCompleteError {
  try {
    sometransaction();
  }  catch(FailedToCompleteError e) {
    // unroll operation or whatever
    throw e;
  }
}

void main() {
  try {
    usebusinessfunction();
  } catch(FailedToCompleteError e) {
    // hmm, what went wrong, should we give up (database) or try again
(bad data)
  }
}

The reason this doesn't map so well onto Vala/GError, is that
something like DatabaseError would probably be unchecked, and so could
trickle through the stack without handlers being invoked to do things
like unrolling transactions.  The aim here is to insulate the business
function from having know that the database even exists, while still
letting it know whether the transaction was completed.  Wrapping the
error preserves the information for the application, or whatever
integration layer actually knows how the stack is set up.

> article> The main reason one would use exception wrapping is to prevent the
> article> code further up the call stack from having to know about every
> article> possible exception in the system.
>
> Well, so the code further up the call stack is not going to look at the
> inner exception anyway except to print it to the operator, right? But for
> that, it's enough to embed the wrapped error's message into the wrapping
> error message. The error code is not relevant.
>
> By the way, you should be suggesting things like this on the Gtk list, not
> here.
>
> --
>                                                 Jan 'Bulb' Hudec <bulb ucw cz>
> _______________________________________________
> Vala-list mailing list
> Vala-list gnome org
> http://mail.gnome.org/mailman/listinfo/vala-list

-- 
Phil Housley