Re: GException notes




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]