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 <xxxxxx@ccil.org>: >> 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". Marc