Re: [Vala] Wrapping Errors with g_prefix_error?
- From: Jan Hudec <bulb ucw cz>
- To: Yu Feng <rainwoodman gmail com>
- Cc: gtk-devel-list <gtk-devel-list gnome org>, vala-list <vala-list gnome org>
- Subject: Re: [Vala] Wrapping Errors with g_prefix_error?
- Date: Sat, 22 Aug 2009 21:03:32 +0200
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 <bulb ucw cz>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]