Re: GException notes
- From: David Benson <daveb idealab com>
- To: gtk-devel-list redhat com
- cc: Havoc Pennington <rhp zirx pair com>, kenelson sequoia ece ucdavis edu
- Subject: Re: GException notes
- Date: Tue, 1 Feb 2000 19:14:05 -0800 (PST)
I think what I would like more, and what would be less
burden on the users, would be a standardized,
typed GError structure to be used as the user wanted.
The only methods I want are constructors, destructors,
and a string for printing.
(A copy constructor too)
In gtk+, I think a convenient use is to have a standard
"error" object data:
some_object_method(object);
error = gtk_object_get_error(object);
if (error != NULL) {
/* Cope with the problem. */
}
Which one could implement:
GError* gtk_object_get_error(GtkObject* object)
{
return (GError*) gtk_object_get_data(object, "error");
}
Also convenient for:
g_return_if_fail(gtk_object_get_error(object) == NULL);
Although probably debugging checks aren't a great idea with
an error system.
Of course
gtk_object_set_error(GtkObject*, GError*);
would be necessary...
- Dave
On 1 Feb 2000, Havoc Pennington wrote:
> Tim Janik <timj@gtk.org> writes:
> > rather, something like a global error entity that could be set would
> > be more appropriate, but still doesn't satisfyingly solve the above
> > case where C() and D() have error conditions that we might want to
> > see handled by A().
> >
>
> The single global error object is _broken_ in that case, not merely
> unsatisfactory. The stack is also _broken_ unless you have a return
> value or other mechanism to distinguish "fatal errors" from "side
> effect errors that some callback happened to set."
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]