2009/8/22 Jan Hudec <b...@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 <b...@ucw.cz> > _______________________________________________ > Vala-list mailing list > vala-l...@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list > -- Phil Housley _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list