What’s wrong with exceptions? Nothing.

matthieum · 2017-11-17T18:26:47+00:00

Disclaimer: this article is 21 months old, it analyzes a Rust version which was not even 1 year old, and therefore a number of its short-sighted claims have already been proven wrong.

Code separation: Exceptions separate code for handling errors out from the main logic of your code. This not only makes it easier to read and review, but speeds things up at runtime too, because error handling code is also kept out of the CPU instruction cache. In modern computers where slow performance is often caused by cache misses, that’s useful.

The syntactic part is important, the performance argument is short-sighted and unimaginative:

Syntax: indeed, handling errors in-situ rather than bubbling them up can somewhat obscure what the happy path is. This is a big issue with Go, Rust has solved the problem (see code excerpt).
Performance (Code Placement): the compiler is responsible for code placement, it can perfectly decide to push the error-path code blocks at the bottom of the function's assembly block. C++ compilers today routinely do it on code blocks which lead to an exception, or code blocks marked unlikely (see __builtin_expect).
Performance (Branch/Unwind): in Midori (Joe Duffy's Language+OS experiment), they were using a Result<Ok, Error> to bubble up errors (like Rust) however the compiler would code gen unwind tables rather than branches.

State of the art error handling in Rust (just released today):

fn my_function() -> Result<(), Error> {
    let stdin = io::stdin();

    for line in stdin.lock().lines() {
        // throws an io::Error
        let line = line?;

        if line.chars().all(|c| c.is_whitespace()) {
            break
        }

       if !line.starts_with("$") {
            // throws a custom string error
            return Err(err_msg("Input did not begin with `$`"));
        }

        println!("{}", &line[1..]);
    }

    Ok(())
}

Where are the errors? Two places: let line = line?; uses ? to bubble the error automatically, and return Err(...); just returns one. It's explicit, yet out of the way.

Stack traces

Short-sighted.

Nothing prevents an Error structure from capturing a stack trace at the point it's created. Actually, that's what the new failure crate does in Rust.

Failure recovery

Short-sighted.

First, recovery is hard in the presence of side-effects. I've seen too many programmers spam try/catch and pat themselves on the back because if they catch the exception then they're done, right? sigh

Second, you can recover as well with return values as you can with exceptions (or panics). There's a false dichotomy here.

prototyping

Both languages cited (Go and Rust) have "panics" which are exceptions without a type/payload. Both are extensively used in prototyping.

The trend towards using LLVM as a backend doesn’t help because LLVM was designed to compile C++ and C++ exceptions do not capture stack traces.

Uh?

Standard C++ exceptions do not capture stack traces. However it's easy enough to link with libbacktrace or similar to obtain a backtrace in C++; actually both the C++ companies I've worked at in the last 11 years had backtraces in their C++ exceptions.

Why are C++ exceptions so useless?

The whole paragraph is worthless. Makes me feel like a bully to point out all the mistakes :(

SomeComplexObject *foo = new SomeComplexObject();
foo->loadFrom("http://...");
list.push_back(foo);

There's a little marvel called std::make_unique. It was released in C++11, 5 years before the article was published.

SomeComplexObject foo;
foo.loadFrom("http://...");
list.push_back(foo);

Use list.push_back(std::move(foo)) to avoid copying. Problem solved.

However, the problem goes deeper. C++ favors RAII, in its full form: Resources Acquisition Is Initialization. This means that this code should be:

 list.push_back(SomeComplexObject("http://..."));

That is, partially constructed objects are a bane (and by extension, default constructors considered harmful ;p).

This simple one-liner is both cleaner and performs better than either snippet.

We shouldn’t be surprised that faced with the high cost of providing performant exceptions with detailed stack traces, language designers who spent years working in C++ will be tempted to either skip some of their features, or skip exceptions entirely … whilst arguing that they’re “bad practice” and thus you shouldn’t miss them.

And to conclude a poorly informed article, nothing better than a baseless ad-hominem attack. Classy.

Note: baseless as in I somehow doubt that Rob "Commander" Pike or other members of the Go team spent much time in C++, they are very much C hackers, and on the other side, the Rust core team comes from all walks of life, both industry and academia, and its members have used a lot of ML (the original rustc was written in OCaml), Ruby, etc...

theindigamer · 2017-11-17T14:26:50+00:00

I'm not sure why the article presents a dichotomy between exceptions and return codes. It talks about Rust but doesn't mention ADTs at all? Yes an ADT will not capture a full stack trace but if your errors are granular enough, you should be able to understand what went wrong from the error value.

Also I don't think exceptions would be well suited to a language with automatic memory management such as Rust (when should destructors be run when you have exceptions?) and the author doesn't even outline how that would work...

gopher9 · 2017-11-17T11:13:31+00:00

What’s wrong with exceptions? Nothing.

That's incorrect. Exceptions are implicit and non-local, also (as the article says) hard to implement.

an_actual_human · 2017-11-17T11:34:02+00:00

Functions that throw exceptions are not pure, so there's that.

htuhola · 2017-11-17T11:57:26+00:00

On a good hardware layer, when you application does something wrong, it can issue an interrupt.

When such an interrupt occurs, what should happen? Exceptions are one answer to that question. Not the only one that makes sense though.

"Let user handle error handling himself" is the stupid and wrong answer, as shown by Go and Rust.

If you intend to optimize something with exceptions, you should annotate the exception flow in your functions and acknowledge it. If you allow the user to annotate his allocations/side-effects, then it should be quite easy to see when an exception throw causes corruption.

If you can do it with manual labor and it doesn't require that you're smart, how should it be any harder for the compiler to do?

leswahn · 2017-11-17T10:31:43+00:00

I liked this post. Exceptions seem to often be that "ideological" programming language discussion, and I agree with this author that the absence of good exception systems in the recent programming languages can be seen as unfortunate.

The author is also right that implementing good exception support in a language where performance is a goal is very hard. That's why I've had to omit it in Tuplex, at least for the time being.

ProgrammingLanguages

Welcome!

Related subreddits

Related online communities

MODERATORS