Email list hosting service & mailing list manager

Brittle exception tests Marc Nieper-Wißkirchen (16 Jun 2020 07:37 UTC)
Re: Brittle exception tests Wolfgang Corcoran-Mathe (16 Jun 2020 19:19 UTC)
Re: Brittle exception tests Marc Nieper-Wißkirchen (16 Jun 2020 20:19 UTC)
Re: Brittle exception tests John Cowan (16 Jun 2020 21:45 UTC)
Re: Brittle exception tests Marc Nieper-Wißkirchen (17 Jun 2020 10:33 UTC)
Re: Brittle exception tests Wolfgang Corcoran-Mathe (17 Jun 2020 22:19 UTC)

Re: Brittle exception tests Wolfgang Corcoran-Mathe 17 Jun 2020 22:18 UTC

On 2020-06-16 22:18 +0200, Marc Nieper-Wißkirchen wrote:
> In the error test for `maybe-join', there is not much to test because
> "it is an error" does not have to be signaled. Your test only tests
> your specific implementation, not any portable implementation. In my
> opinion, portable test suites are most helpful (because they encourage
> alternative implementations), so I would drop that particular test.
> And I would use `assume' of SRFI 145 instead of `error' in the sample
> implementation because `assume' is exactly for these "it is an error"
> cases.
>
> The same comment holds for all other occurrences of `catch-errors'
> except for the test for `maybe-if', where the specification says that
> an error is signaled. Here, you cannot use `error-object?' either in a
> portable test because a portable implementation may not use `error' to
> signal the error but use `raise' on some implementation-defined
> object. Thus, you cannot guard against such an error portably (except
> with a catch-all guard, which is brittle for tests and which should be
> a no-go for programs).

Thanks for the explanation, and for bearing with my ignorance.  I'll
remove the tests for the "it is an error" cases, and use `assume',
rather than `error', for those cases in the implementation.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>

"It from bit." --John Wheeler