> Defect is not part of the effect system, not meant to be caught and has a
> compiler option/dialect to disable it / turn it into a panic meaning you
> can't rely on it in libraries.
That's true, however: The mere possibility of offering "continue after a panic"
means that the standard library has to use `defer: resource.close` instead of
the mere `resource.close` call. And every other library is better when it does
the same. Historically, this has been one major source (but of course not the
only source) of exception handling bugs in the standard library, especially
because there was a strong incentive to avoid the `try` statement ("it is
slow!"). A great deal of simplicity is gained when the language does not allow
to continue after a panic. Apparently I consider this problem to be much more
important than you do, however you go on with
> We'd actually prefer that a number of the current defects become part of the
> effect system as well, including array access and integer overflow, such that
> raises: [] prevents them from being ignored at that boundary.
which seems to imply that you want "panic tracking" too. Nothing wrong with
that, of course, but it does weaken the distinction between panics and
exceptions.
> Result offers this as a feature, so that primitive libraries can easily be
> built exception-free while usage in exception-based code is .. simple.
True I suppose but the reverse is quite easy too, isn't it:
type
Either[T] = object
case valid: bool
of false: e: ref Exception
else: val: T
template toEither(call): untyped =
(try: Either[typeof(call)](valid: true, val: call) except:
Either[typeof(call)](valid: false, e: getCurrentException()))
import os
echo toEither(os.getAppFilename())
Run
