I agree that we need to clarify our error-handling story. Specifically I
would like Daniel to elaborate on this quote of his from the previous
thread, with potential solutions at the language level:
> Rust's task failure isn't very isolated or robust. A failure in a
> destructor called during failure will abort the process. A failure in a
> destructor when not already failing will not call the inner destructors
> as it would be memory unsafe.
>
> A failure also has to poison RWLock / Mutex so that all other threads
> with handles to the same shared data will fail too. I don't think these
> issues are going to be fixed, unwinding in a language with destructors
> is just inherently broken.
>
> I think process separation is a far better option for robust systems.
On Sun, Jun 22, 2014 at 10:29 AM, Gábor Lehel <glaebho...@gmail.com> wrote:
>
> On Sun, Jun 22, 2014 at 2:02 AM, Daniel Micay <danielmi...@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@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>>
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
>
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
