Re: [Vala] Wrapping Errors

[Yu Feng <rainwoodman gmail com>]

On Thu, 2009-09-03 at 13:38 +0100, Phil Housley wrote:
> 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.
In vala, to wrap up errors one can always do(because the essence part of
the error in Vala is merely the .message field):

private void dbaccess() throws DBError(e) {
        throw new DBError.ACCESS_FAILED("db access failed");
}

public void sometransaction() throws TransactionError {
        try {
                dbaccess();
        } catch(DBError e) {
                throw new TransactionError.FAILED_COMPLETE("Failed to complete: %s",
e.message);
        }
}
public void somebusiness() throws BusinessError {
        try {
                sometransaction();
        } catch(TransactionError e) {
                throw new BusinessError.FAILED_TRANSACTION("Business Failed: %s",
e.message);
        }
}

I hope I understood what you were trying to say.

Yu
> > 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