On Thu, 2009-09-03 at 13:38 +0100, Phil Housley wrote:
> 2009/8/22 Jan Hudec <[email protected]>:
> > 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
> > <[email protected]>
> > _______________________________________________
> > Vala-list mailing list
> > [email protected]
> > http://mail.gnome.org/mailman/listinfo/vala-list
> >
>
_______________________________________________
Vala-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/vala-list
