Exception handling

[ludovic.courtes@laas.fr (Ludovic Courtès)]

Hi,

Neil Jerram <neil@ossau.uklinux.net> writes:

> ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>
>> Indeed, this exception model is not very convenient.  In some cases,
>> it's even hardly usable, as examplified by the `test-suite/lib.scm'
>> hacks (use of regexps to parse exception messages and determine their
>> meaning...).
>
> IMO this isn't so bad.  Using a regexp to check an exception message
> makes sense (i) because the message is part of the interface, and so
> worth checking,

Indeed, the message conveys additional information about the exception,
and as such, it may need to be checked.

Now, I disagree that a text message, whose primary purpose is to be
human-readable --- in fact, it should even be translated depending on
the current locale, as for `strerror(3)' --- is the "right way" to
implement communication among modules (or programs, or procedures).

Such a string, in general, has to be "parsed" in order for the program
to extract its meaning (that's what the regexp does).  This process is
error-prone, unreliable, and inefficient.  Since Scheme provides a wide
range of types (and Guile allows the definition of additional types), it
may be wiser to use typed objects directly to communicate exception
information among different modules.  (In the end, it all boils down to
arguing about typed languages compared to string-oriented languages like
Unix shells.)

> and (ii) because there will never be a distinct
> exception key (or condition type, or whatever) for every possible
> exception that can be thrown.

Well, Java successfully deals with that, as most modern languages and
implementations do.  SRFI-3[56] provide a practical way to implement
that in Scheme.

Now, just because dozens of different exception types may be thrown by a
given program (or procedure) doesn't mean that its callers/users have to
handle each one of them gracefully.  However, callers and users should
have the _ability_ to cope with exceptions that they know they can
recover from in a useful way.

> Yes, although I prefer a code solution to a documentation one, if that
> is possible.

Sure.

> Since people seem to like SRFI-35/36, one option would be to provide a
> procedure that would convert a set of throw args into the closest
> matching SRFI-35/36 condition.
>
> A developer could choose to use this in their handler procs, and then
> use SRFI-35/36 procedures to interrogate the condition further.
>
> If this is possible (which it might not be, because I'm not sure
> the SRFIs define enough condition types yet), would it be an adequate
> solution?

I don't know.  Do you mean something like:

  (catch #t
    (lambda ()
      ...)
    (lambda exception-args
      (let ((condition (guile-exception->srfi-35 exception-args)))
        ;; Handle CONDITION...
        ...)))

I think this would be quite inconvenient.

For my own procedures, I use SRFI-35 (from Guile-lib) and SRFI-34 (from
Guile core) do deal with exceptions.  Unfortunately, native Guile
exceptions (like, say, `system-error') cannot be dealt with in the same
way.

Maybe SRFI-34 is the place where a transparent compatibility layer from
Guile's native key+args to SRFI-3[56] exceptions could be implemented?
For instance, before invoking the handler, it checks whether the "key"
argument of the exception is `srfi-34' or something else, and if it's
something else, it tries to convert it to the relevant condition type.

What do you think?

Thanks,
Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user