Re: Improving R6RS exception handling in Guile

[Ludovic Courtès]

Mark H Weaver <address@hidden> skribis:

> As noted by Göran Weinholt in <http://bugs.gnu.org/14922>, the R6RS
> exception handlers in Guile are currently unable to catch native Guile
> exceptions.  To fix this, the basic approach of this patch is to convert
> native Guile exceptions into R6RS conditions within the R6RS exception
> handlers.
>
> It's almost that simple, but there's one twist: if an R6RS exception
> handler chooses not to handle a given exception, it will call 'raise'
> again on the condition object, and here we must arrange to throw the
> original Guile exception again.  We must do this because there's a lot
> of Guile code out there that can only handle native Guile exceptions,
> and which should not be broken by an R6RS exception handler somewhere in
> the middle of the call stack.
>
> We cope with this by including a special &guile condition object in the
> compound condition that is produced by conversion.  Whenever 'raise' is
> applied to such a condition, it will use the native Guile 'throw' with
> the original KEY and ARGS stored in the &guile condition object.

Makes sense to me (and indeed a bug worth fixing!).

> +  ;; TODO: Arrange to have the needed information included in native
> +  ;;       Guile I/O exceptions, and arrange here to convert them to the
> +  ;;       proper conditions.  Remove the earlier exception conversion
> +  ;;       mechanism: search for 'with-throw-handler' in the 'rnrs'
> +  ;;       tree, e.g. 'with-i/o-filename-conditions' and
> +  ;;       'with-i/o-port-error' in (rnrs io ports).

Yeah, the generic approach of this patch is going to be better than the
(rnrs io ports) hacks.  :-)

> +  ;; XXX TODO: How should we handle the 'misc-error' and 'signal' native
> +  ;;           Guile exceptions?

Maybe &guile-error as a sub-type of &error?  (What’s ‘signal’?)

> +  ;; XXX TODO: Should we handle the 'quit exception specially?

&guile-quit?

> +  (pass-if-condition "syntax-error"
> +                     syntax-violation?
> +                     (eval '(let) (current-module)))

(put 'pass-if-condition 'scheme-indent-function 1)

> +  (pass-if-condition "regular-expression-syntax"
> +                     assertion-violation?
> +                     (make-regexp "[missing-close-square-bracket"))
> +
> +  (pass-if-condition "null-pointer-error"
> +                     assertion-violation?
> +                     (dereference-pointer (make-pointer 0)))

Regexp and the FFI are libraires.  Do we really want to convert these
too?  Where do we stop?

Thanks,
Ludo’.