Why only assertion violations? Daphne Preston-Kendal (24 Oct 2024 19:04 UTC)
Re: Why only assertion violations? Wolfgang Corcoran-Mathe (26 Oct 2024 16:25 UTC)
Re: Why only assertion violations? Marc Nieper-Wißkirchen (26 Oct 2024 16:30 UTC)
Re: Why only assertion violations? Wolfgang Corcoran-Mathe (28 Oct 2024 18:11 UTC)
Re: Why only assertion violations? Daphne Preston-Kendal (28 Oct 2024 18:14 UTC)
Re: Why only assertion violations? Marc Nieper-Wißkirchen (28 Oct 2024 18:32 UTC)
Re: Why only assertion violations? Wolfgang Corcoran-Mathe (29 Oct 2024 17:55 UTC)

Re: Why only assertion violations? Marc Nieper-Wißkirchen 28 Oct 2024 18:32 UTC

Am Mo., 28. Okt. 2024 um 19:13 Uhr schrieb Daphne Preston-Kendal
<xxxxxx@nonceword.org>:
>
> On 26 Oct 2024, at 18:29, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
> > The "restartable" form is to enable users to replace procedure
> > arguments in case of inadequate arguments delivered to a procedure.
> > The condition type for the latter exception is the assertion
> > violation.  Thus, it is out of the scope of the original idea of the
> > "restartable" form to consider other condition types.
>
> An inadequate argument could be the path to a file which is expected to exist but does not, which is not an assertion violation.

Right, but that should be covered by a different form.  For example,
restarters for file errors should probably be established around the
procedures actually handling files, not around an arbitrary procedure
that just happens to be in the call stack