2009/9/3 Yu Feng <[email protected]>: > 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
While that is true in a sense, you lose the actual meaning of the error, unless you want to do something nasty with parsing the message strings. As I said, GError has less need for exception wrapping, simply because it is no where near as powerful as other languages versions. In Java it is perfectly practical to pack any amount of data into an exception, and then recover this to decide how to handle the situation. GError is much more about just saying that a method has encountered a problem. >> > 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 >> > >> > > -- Phil Housley _______________________________________________ Vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
