Exception handling (was: Quickies about the new GObject)
- From: Derek Simkowiak <dereks kd-dev com>
- To: Havoc Pennington <hp redhat com>
- Cc: gtk-devel-list redhat com
- Subject: Exception handling (was: Quickies about the new GObject)
- Date: Thu, 1 Jun 2000 12:56:58 -0700 (PDT)
-> > I've been learning about Java lately, and it seemed that if Glib
-> > will have signals, we could use the Java model of throwing exceptions
-> > (implemented in the form of GObject signals) to have structured error
-> > handling.
->
-> Signals don't work anything like exceptions, I don't know how that
-> would work.
Maybe I'm stuck in the Unix signal paradigm.
What I had in mind was an GException class (with error-specific
children, as in Java).
Then, when a particular test fails (i.e., opening a file fails
because the file is not found) a GObject signal with the name "exception"
is emitted. The gpointer "data" for that "exception" signal is a pointer
to the GException child object corresponding to the error (i.e., to a
GFileNotFoundException object filled in with the pathname, etc.)
GObject would have a default signal handler for the "exception"
signal that would have actions for every type of Exception (i.e., {
g_print("Couldn't find file %s", filename); } ). It would use the GObject
type system, implemented as those lovable GTK_IS_BUTTON macros in the
current system, to see what kind of exception object was attached to the
"exception" signal and take the appropriate action in a big switch
statement.
The app developer could attach his own signal handler to the
"exception" signal and take special custom actions if a particular
GException child was being passed. If you didn't wan't the default
actions to take place, you could just stop the signal after executing your
custom code (i.e., pop up a dialog box instead of using g_print for
GFileNotFoundException).
The app developer could create his own GException children
objects and handle them with his custom "exception" signal handler. This
would allow for his own customized error handling, with special exceptions
like GOutOfAmmoException or GDoorIsLockedException in a Mario game.
I'm just getting into Java, but this sounds to me like Java's
exceptions. A "throw" is a signal emission of the "exception" signal.
--Derek
P.S.> This system is completely off-the-cuff, and not thought through. I
had assumed you guys considered something like this already...
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]