I had actually forgotten that, which somewhat reconciles me to it.  But I still want it to be a (first-class) procedure, not a (second-class) macro, something like this: (exception->either exeception-pred thunk).  This is a little more verbose (an extra lambda) in the case you give, but brings more flexibility in use: it can, for example, be mapped over a list of thunks to be invoked to produce a list of Eithers. Here's an untested implementation sketch:

(define (exception->either pred thunk)

  (with-exception-handler

    (lambda (e)

      (if (pred e)

        (left e)

        (raise-continuable e)))

    (lambda ()

      (right (thunk)))))

I do not think it is worthwhile to devote a dedicated predicate to catching exceptions of this type, and I think it would set a bad example.  However, "an error satisfying error-object?" works for me, and I have changed the phrase both here and in SRFI 186.

It turns out (and I didn't know this subtlety) that when the CL spec says "an error is signaled", that is precisely what it means: a condition object of type `error` is signaled.  If I had known that, I would have pushed to write it into R7RS-small.  There aren't many SRFIs that contain the phrase, either, and most of them are either withdrawn or not in use.

In any case, the above changes plus the claw clarification (it did mention an identifier as claw, but didn't say it has to be bound) are now pushed to johnwcowan/srfi-189.

John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
When I wrote it I was more than a little febrile with foodpoisoning
from an antique carrot that I foolishly ate out of an illjudged faith
in the benignancy of vegetables.  --And Rosta