[rust-dev] Recoverable and unrecoverable errors (Was: Re: Integer overflow, round -2147483648)

Gábor Lehel glaebhoerl at gmail.com
Sun Jun 22 07:29:45 PDT 2014

On Sun, Jun 22, 2014 at 2:02 AM, Daniel Micay <danielmicay at gmail.com> wrote:

> On 21/06/14 07:55 PM, Benjamin Striegel wrote:
> >> No one will use Rust if it's slow. If it uses checked arithmetic, it
> >> will be slow. There's nothing subjective about that.
> >
> > This is the only argument that matters.
> >
> > If we are slower than C++, Rust will not replace C++ and will have
> > failed at its goal of making the world a safer place. The world already
> > has a glut of safe and slow languages; if inefficiency were acceptable,
> > then C++ would have been replaced long ago.
> >
> > In addition, bringing up hypothetical CPU architectures with support for
> > checked arithmetic is not relevant. Rust is a language designed for
> > 2014, not for 2024.
> >
> > And if in 2024 we are all suddenly gifted with CPUs where checked
> > arithmetic is literally free and if this somehow causes Rust to be
> > "obsolete" (which seems unlikely in any case), then so be it. Rust is
> > not the last systems programming language that will ever be written.
> Not only does the hardware have to provide it, but each OS also has to
> expose it in a way that Rust could use to throw an exception, unless the
> proposal is to simply abort on overflow. LLVM would also have to gain
> support for unwinding from arithmetic operations, as it can't currently
> do that. Even with hardware support for the operation itself, giving
> every integer operation a side effect would still cripple performance by
> wiping out optimizations.

This is going off on a tangent (and I hope editing the subject will make
gmail consider it a separate conversation), but I've been bothered for a
while by our apparent lack of distinction between, as I've heard them
referred to, recoverable and unrecoverable errors. Unrecoverable errors are
programmer errors. Per their name, they are not recoverable. They don't
"happen" at runtime, or even compile time, but at program-writing time, and
the only way to recover from them is to go back to program-writing time and
fix the program. Things like out-of-bounds array accesses, accidental
overflow, `assert`s and `debug_assert`s would belong in this category.
Meanwhile, recoverable errors are merely problems which occur at runtime,
and it should be possible to recover from them.

Task failure, recoverable from without the task but not within it, is kind
of neither here nor there.

What if we *did* move to program abort for unrecoverable errors?

And what if we did (eventually) grow an actual exception handling system
for (some) recoverable errors? We'd enforce the same isolation guarantees
for `try { }` blocks as we do for tasks - in other words, a `try` block
couldn't share state with the rest of the function - so exception safety
would continue to not be a concern. (I know we have `try()`, but it's kind
of coarse and has an up-front performance cost.) To me, the hard part
doesn't seem to be exception safety, but figuring out what things can be
thrown and how they are caught, whether they're part of function signatures
or exist outside them, and so on. The
catches-based-on-type-of-thrown-object mechanism used by existing languages
doesn't appeal to me, but I don't have many better ideas either.

> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140622/6b076536/attachment.html>

More information about the Rust-dev mailing list