GNU bug report logs -
#66776
SRFI-64 test-error doesn't match error types
Previous Next
Full log
View this message in rfc822 format
On 27.10.2023 20:40, Maxim Cournoyer wrote:
>
> There is a more modern implementation of SRFI-64 out there for Guile
> which may provide clues or be used wholesale, though I haven't tried it:
> <https://codeberg.org/taylan/scheme-srfis/src/branch/master/srfi/64>.
>
FYI, this is how I check whether a caught error matches the 'type':
(define (error-matches? error type)
(cond
((eq? type #t)
#t)
((condition-type? type)
(and (condition? error) (condition-has-type? error type)))
((procedure? type)
(type error))
(else
(let ((runner (test-runner-get)))
((%test-runner-on-bad-error-type runner) runner type error))
#f)))
Defined on Line 336 in execution.body.scm:
https://codeberg.org/taylan/scheme-srfis/src/branch/master/srfi/64/execution.body.scm#L336
In summary, other than #t to match anything, 'type' can be:
- A SRFI 35 condition-type object
- A procedure, which will be called as a predicate on the error
The predicate case should cover the Guile and R6RS exception systems,
which both simply use predicates to detect condition/exception type
from what I can tell:
https://www.gnu.org/software/guile/manual/html_node/Exception-Objects.html
https://www.gnu.org/software/guile/manual/html_node/rnrs-conditions.html
--
Taylan
P.S.: The warning on Codeberg re. invisible Unicode characters is from
using ^L to delineate file sections for navigation with Emacs.
This bug report was last modified 210 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.