bug#66776: SRFI-64 test-error doesn't match error types

Taylan Kammer <[email protected]>
Newsgroups gmane.lisp.guile.bugs
Message-ID <[email protected]>
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.