Did Rust make the right choice about error handling?

[daboross]

@ZiCog

• Running out of memory. Stack or heap.
• A bug in your code.

On the topic of panics, it's idiomatic to panic in both of these situations today, and the behavior ends up pretty identical to an unchecked, uncaught exception in languages with exceptions.

For hardware error/failure, if it's something we're communicating with, I'd argue some nicer error message could be warranted (and the program could recover). If it's hardware we're running on, like ram or CPU errors, then I'd say all bets are off and killing the program is probably reasonable.

I quite like rust's separation of these two concepts - "recoverable errors" are in your face with Result, and unrecoverable ones, like program bugs, unconditionally unwind the stack and crash.

There's a bit of an odd situation where panics only crash a single thread, and not the whole program, but they can often be propagated through the program through poisoned mutexes and closed channels anyways.

[ZiCog]

@tech6hutch

I think the usual arguments in favor of exceptions are:

1. They can require less thinking about errors (for better or for worse), since errors aren't part of the function's return type. Rewriting a function to be fallible also takes less effort. (This could be mitigated a bit with syntax sugar, as withoutboats suggested.)

I have heard that argument a lot. I think it is obviously false. Consider:

A simple program to add two numbers can produce the correct answer or it can fail. One has to think about what do do in both cases. In the happy case we might want to print the result. In the sad case what? Crash an burn? Exit with nothing? Print the wrong result? Might be nice to think about it and do something helpful like print "Overflow error".

Sure exception keep the error out of the happy path so you don't have to think about it there. But you have to think about it somewhere no matter what mechanism you have to detect errors.

Scale that up to the thousands of errors that can happen in a large program and add the fact that we often want to keep running in the face or errors (Unless they are truly exceptional). There is no "less thinking" about it any which way.

Given all that we see that hiding the error situations under the rug with exceptions really obfuscates what you need to think about.

@tech6hutch

2. They're useful if a situation is truly exceptional, since there's neither the syntax nor runtime overhead of error handling as long as we're in "the happy path".

To my mind "truly exceptional" you cannot handle. Better to die immediately.

@tech6hutch

Overall, I prefer Rust's approach.

Exactly.

[isaac]

Just a quick semi-related question: What's the idiomatic way of returning a result with multiple errors in Rust? Should we do something like:

enum Errors {
    Whoops(String),
    Thats,
    An { location: usize, offset: usize},
    Error,
    ...
} 

type ErrorResult<T> = Result<T, Errors>

Or:

enum ErrorResult<T> {
    Ok(T),
    These(String),
    Are,
    AllErrors { kind: String, message: String },
    ...
}

The benefit of using a Result is the try (?) operator, but to me it seems like the latter method is more correct. Thoughts?

[alice]

The first is the idiomatic solution. You make a single type for holding an error, and only errors.

[domibay-hugo]

As a Conclusion of the Analysis of the concrete Use Case of UTF8Error Handling as discussed at:

Error handling and UTF-8 validation

In regards to the Question "Does correct Error Handling add to the Processing Time?" The Profiling Analysis shows that the correct Error Handling doubles the Processing Time: The Community suggested version with minimal Parsing: $ date +"%s.%N" ; target/release/text-sanitizer_v2 -i < lanzarote-com_de-ausfluge.html >/dev/null ; date +"%s.%N" 1589793780.372181577 Input time: 43.534µs Parse time: 203.554µs Total time: 354.7µs 1589793780.377126057 $ echo "scale=3; 80.377126057-80.372181577"|bc -l…

I found that the correct Processing and Recovery of the UTF8Error bloats up the Application Logic and thus produces a measurable increment of the Processing Time

[red75prime]

BTW. Is there something preventing compilation of unhappy path of (at least some) code, which uses Results, into side-tables? Like it is done with exceptions.

[ZiCog]

@domibay-hugo

I found that the correct Processing and Recovery of the UTF8Error bloats up the Application Logic and thus produces a measurable increment of the Processing Time

I'm curious. Do you have a github repo or such that contains both Rust and whatever other language solutions to that problem? I'd like to see what is going on there.

[domibay-hugo]

I published all my Rust Code in the Playground Links.
So all commands and results of the analysis are fully reproduceable.

[ZiCog]

Yes, I know. I tried to follow that.

A single link to the best performing Rust and whatever other language solution would be great.

One needs both to make a valid comparison.

[domibay-hugo]

The community suggested this version:

Rust Playground

The version that produces the correct result is this one:

Rust Playground

The test for correctness would be like this:

$ echo $(perl -e 'my @arrchrs = (226, 157, 164, 240, 159, 146, 150, 119, 250, 248, 240, 159, 146, 150, 247, 190); print pack "U*", @arrchrs; print "\n";'; date +"%s.%N") |target/release/text-sanitizer ; date +"%s.%N"

The Test Data is this Web Page as static Text file:

$ echo $(wget -S -O - "http://www.lanzarote.com/de/ausfluge" 2>&1) > lanzarote-com_de-ausfluge.html

Now the Question is: "Can the Parsing Function sanitize_u8() be rewritten in a way that it can produce the correct result in 200µs?"

That was actually the argument of the whole discussion.

[Cerber-Ursi]

@domibay-hugo

Can the Parsing Function sanitize_u8() be rewritten in a way that it can produce the correct result in 200µs ?

The question to you is - can it be rewritten in any other language in this way? It seems that in C you've got the performance you want?

[ZiCog]

It's impossible domibay-hugo, I cannot fathom the exact requirement from that mass of code.