Re: saving and restoring the error stack trace

[Neil Jerram <neil@ossau.uklinux.net>]

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, and (ii) because there will never be a distinct
exception key (or condition type, or whatever) for every possible
exception that can be thrown.

> Ideally, Guile should use some SRFI-3[56]-like mechanism to represent
> exceptions.  Unfortunately, I don't think this could be done without
> breaking compatibility.

Agreed.  I've spent some time thinking about this and haven't found a
solution yet.

> In any case, documenting the exceptions thrown by the built-in
> procedures would certainly help.

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

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?

Regards,
     Neil



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