Wrapping Errors

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Wrapping Errors

Yu Feng-3
Dear List,

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 

GError will need an extra field for chaining up the causes. gerror.h
doesn't have any preserved bytes for an extra field. However, because
GError is always accessed by pointers and no GLib program is supposed to
statically allocate memory for GError, it should be safe to append an
field to the internal structure of GError while keeping the ABI
compatible.

Two new proposed functions:

GError * g_error_new_with_cause(GQuark domain, gint code, GError ** cause, const char* format, ....);
Returns an new GError with `cause' as its cause. `*cause' is set to NULL.

void g_set_error_with_cause(GError ** error, GQuark domain, gint code, GError ** cause, const char * format, ...);
sets *error to an error caused by *cause if error is not NULL. if error is NULL, free *cause.

g_error_free should be modified so that all the chained up errors are freed.


Example:
my_function(GError ** error) {
  GError * tmp_error = NULL;
  some_io_function(...., &tmp_error);
  if(tmp_error != NULL) {
     g_set_error_with_cause(error, MY_ERROR, MY_ERROR_NUMBER1, &tmp_error, "some random error caused by some_io_function");
     return;
  }
  /** do something else **/
}

Regards,


Yu

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [Vala] Wrapping Errors

Jan Hudec
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.

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 <[hidden email]>
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [Vala] Wrapping Errors with g_prefix_error?

Yu Feng-3
On Sat, 2009-08-22 at 09:24 +0200, Jan Hudec wrote:

> 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.
>
> 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.
>
I buy your point.

In an language like Java, the error(Exception) carries more than a
message and a code. It also includes a source code reference therefore
it make sense to save the cause as an data member.

Nevertheless in the GObject case, because the error only carries an
code, and a message, there is no need to wrap the low level errors.
g_prefix_error would be sufficient as an substitute of 'wrapping'. How
can we invoke this function in vala though?

> By the way, you should be suggesting things like this on the Gtk list, not
> here.

I thought it was a GObject feature which was highly relevant to Vala.


Yu
>

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [Vala] Wrapping Errors with g_prefix_error?

Jan Hudec
On Sat, Aug 22, 2009 at 11:52:01 -0400, Yu Feng wrote:

> On Sat, 2009-08-22 at 09:24 +0200, Jan Hudec wrote:
> [...]
> > 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.
> >
> I buy your point.
>
> In an language like Java, the error(Exception) carries more than a
> message and a code. It also includes a source code reference therefore
> it make sense to save the cause as an data member.
>
> Nevertheless in the GObject case, because the error only carries an
> code, and a message, there is no need to wrap the low level errors.
> g_prefix_error would be sufficient as an substitute of 'wrapping'. How
> can we invoke this function in vala though?

If you are wrapping an error, you don't need that function. Instead you
create a new error and use the inner error's message as one of the arguments
for the message format string.

The purpose of g_prefix_error is somewhat different. It's used to add context
to the error without wrapping it. For example if you are accessing file and
the function that detects the error only has a stream, the calling function
might prefix it with the filename to indicate where the error happened.

I think it would make sense to add it to the GError class in glib-2.0.vapi --
if you find you have good use for it, just add it there and post a patch.

> > By the way, you should be suggesting things like this on the Gtk list, not
> > here.
>
> I thought it was a GObject feature which was highly relevant to Vala.

Important goal of vala is to interoperate well with non-vala gobject code. So
features like this would need to be added to glib.

--
                                                 Jan 'Bulb' Hudec <[hidden email]>
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Wrapping Errors

Simon McVittie-6
In reply to this post by Yu Feng-3
On Thu, 20 Aug 2009 at 22:09:21 -0400, Yu Feng wrote:
> However, because
> GError is always accessed by pointers and no GLib program is supposed to
> statically allocate memory for GError

Er, is nobody supposed to allocate GErrors statically? That's the first I'd
heard of it...

In code using dbus-glib to implement async methods, it's very convenient to
do things like this:

if (!check_permission(...))
  {
    GError e = { TP_ERRORS, TP_ERROR_PERMISSION_DENIED,
        "no you can't have a pony" };

    dbus_g_method_return_error (context, &e);
  }

to avoid a pointless allocate/free when using functions like
dbus_g_method_return_error (or g_error_copy), which take a const error...
is this forbidden, and if so, by what?

    Simon
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: [Vala] Wrapping Errors

Phil Housley
In reply to this post by Jan Hudec
2009/8/22 Jan Hudec <[hidden email]>:

> 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 <[hidden email]>
> _______________________________________________
> Vala-list mailing list
> [hidden email]
> http://mail.gnome.org/mailman/listinfo/vala-list
>

--
Phil Housley
_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list