[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GOOPS-based SRFI-35 implementation

From: Andreas Rottmann
Subject: Re: GOOPS-based SRFI-35 implementation
Date: Thu, 04 Mar 2004 01:20:19 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

Neil Jerram <address@hidden> writes:

> Andreas Rottmann <address@hidden> writes:
>> Hi!
>> I just wanted to announce that I've been working a bit on a
>> GOOPS-based implementation of SRFI-35 ("Conditions"). It seems to
>> basically work, except compound conditions, which are not-yet
>> implemented. My implementation is based on the SRFI reference
>> implementation, but differs a good deal because it uses GOOPS classes
>> instead of SRFI-9 ("Defining record types"). 
> Without having looked yet at your code, I think this is nice, because
> it ties in with my general thoughts on how we might enhance Guile's
> existing errors and exceptions and unify them with the proposals in
> SRFIs 34, 35 etc.
> So perhaps this is a good time to share and discuss those thoughts.
> In my view there are two main problems with Guile's current
> errors/exceptions.
> - A given error/exception - i.e. a collection of throw args - is not
>   at all self-describing as regards how the catcher should deal with
>   it, print an error message, etc.
> - There is no way to say sthg like "I want to catch all system
>   errors", or "all numerical erros".
I've thought of this, too; this was my reason to use GOOPS in the
first place.

> I think the solution to both these is that an error/exception should
> be an instance of a GOOPS error/exception class (+ subclasses).  The
> first problem is then solved by the class slots showing what
> information is available about the error/exception, and class methods
> to - for example - print a human-readable message describing the
> error/exception.
So far, this is all implemented in my srfi-35 stuff as in my
Archive. I have additionally exported a handle-condition generic,
whose methods call (error "unhandled foo"), foo being an error
condition, message, serious condition. Also, there is a class
&compound-condition which doesn't exist in the SRFI (so methods for
compund conditions can be defined). Plus, there is a macro
guard/handle, which calls handle-condition:

(define-method (handle-method (&foobar-condition c))


>  The second problem is solved by arranging
> error/exception classes in an inheritance hierarchy, and enhancing
> `catch' so that it catches all errors/exceptions that satisfy `(is-a?
> KEY)'.
First part (inheritance hierarchy) also done.

> If this is accepted, I further think that the errors/exceptions in the
> new class hierarchy should be identical with the conditions specified
> by SRFI-35.  Therefore, for example, `make-condition' would create and
> return a GOOPS error/exception class and, given a
> error/exception/condition object OBJ, `(condition-has-type? OBJ TYPE)'
> would be identical to `(is-a? OBJ TYPE)'.
I'd have to specialize is-a? for this, since compound conditions all
share a class.

> Even further, I think it follows that `throw' can become identical to
> SRFI-34's `raise', with back-compatibility preserved by translating
>   (throw KEY . ARGS)
> to something like
>   (throw (make <legacy-exception> #:key KEY #:args ARGS))
> Finally, `catch' could be enhanced so that its KEY is either #t, a
> symbol (legacy case) or an error/exception class; and SRFI-34's
> `with-exception-handler' and `guard' provide different catching and
> handler semantics, but operating on the same kind of
> error/exception/condition objects.
> Any comments?
Sounds like a good plan, especially since it's been about that what I
was after ;-)

Cheers, Andy
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden      | GnuPG Key:
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Python is executable pseudocode, Perl is executable line-noise.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]