Email list hosting service & mailing list manager

Brittle exception tests (no sender) (16 Jun 2020 07:37 UTC)
Re: Brittle exception tests Wolfgang Corcoran-Mathe (16 Jun 2020 19:19 UTC)
Re: Brittle exception tests (no sender) (16 Jun 2020 20:19 UTC)
Re: Brittle exception tests John Cowan (16 Jun 2020 21:45 UTC)
Re: Brittle exception tests (no sender) (17 Jun 2020 10:33 UTC)
Re: Brittle exception tests Wolfgang Corcoran-Mathe (17 Jun 2020 22:19 UTC)

Re: Brittle exception tests Marc Nieper-Wißkirchen 17 Jun 2020 10:32 UTC

Am Di., 16. Juni 2020 um 23:45 Uhr schrieb John Cowan <>:

>> As I have already written to John,
>> an error that has to be signaled but which I cannot test against, is
>> not only no more helpful than the condition "it is an error" (as you
>> can see by not being able to write a proper portable test), but even
>> worse than "it is an error" because it disallows the kinds of
>> optimizations underlying the idea of SRFI 145.
> The phrase "an error is signaled" is used when a programming error has occurred and no recovery is reasonably possible, because   Specifically it guarantees that the continuation of the procedure that is signaling will not be called (modulo call/cc tricks).  The only time it makes sense to catch such errors is when you are writing something like a server that must continue to run even if there is a bug somewhere in it.

This is not the sense in which R7RS uses the phrase "an error
signaled" (except for `scheme-report-environment` or
`null-environment`, but this is only in the R5RS compatibility
library). All other signaled errors either satisfy `file-error?` and
`read-error?`. Against these I can guard and can do some error
recovery (by choosing another file, etc.).

> For example, a plausible definition of an `assert` (as opposed to `assume`) macro is "If the argument evaluates to #f, implementation-dependent actions are taken and an error is signaled."

As I have repeatedly commented, signaling an error without a way to
detect it does not help (see also the impossibility of writing a
test). Moreover, the phrase "signaling an error" forbids
implementations to raise low-level errors that cannot be caught by
standard user-provided exception handler.

> It's my view that maybe-if with a non-Maybe first argument is a programming error of exactly this type.

It is certainly a programming error. In some sense it is analogous as
if someone writes something like `(car 0)`. But it is not an error
like `(delete-file "i-do-not-exist.txt")`. Actually, `delete-file` is
a pretty good example, I think, because when `delete` is called with
anything but a string, it is an error, which is exactly what you have
described as a "programming error".

So, I think the intention is "it is an error if `maybe-expr' does not
evaluate to a Maybe and implementations are encouraged to report this
to the user and stop evaluation in an implementation-defined way". But
this is mostly what "it is an error" means in the R7RS.

As a compromise, I would again suggest writing "an implementation
SHOULD signal an error".