Hacker News Reader

Sometimes you want the error case to be fast. That's actually what everyone who is bringing up this argument is implicitly acknowledging by saying that you shouldn't use exceptions for all errors. In that case you need an alternative mechanism for error handling, which is readily provided by Rust's facilities. It is not true that Rust only cares about performance of errors and not ergonomics, and I don't know where that idea came from--that's why we have the try macro and unwrap!

Rust does follow the model of "exceptions for truly exceptional cases"--that's what panic is for. It's implemented with unwinding under the hood, just as in C++, and you can change it to abort if you want.

C++ allows either error cases and non-error cases to be fast, depending on your use case. Rust essentially leads to code where the successful case (which really is almost all code; even in your Eclipse situation, which I will again stress is a flawed datapoint, there is also a ludicrous amount of successful code) is both verbose and slow. What the comments here were indicating is that with a library that has been well thought out, certain kinds of activities that are known to lead to errors that developers need to check in the moment are implemented with case logic while most errors can be left implicit. No: unwrap and try! are the enemy, not the solution. This is like arguing that C++98 solves the ergonomics of types by providing typedef: a better solution is C++11's auto, and the correct solution is inference.

When I have seen Rust code, it is always littered with error propagation logic, which seems to be due to a failure by language designers to realize that most use cases for errors should be using a mechanism like panic, in turn leading to panic being pretty useless: as it can only throw a string, it is impossible to provide the kind of rich context that would be needed 50 levels up the call stack (maybe all the way up in main) to report the error to the user (which ranges from information that is description to that which is technical). This is what most, and I would argue almost all (but going this far seems to require an hour of your time and a whiteboard, as people have been so trained to try to handle their errors constantly :/), use cases for errors are: to store and provide rich context on the error, whether in a log for an administrator or for the operator.

This is what a command line tool does with almost all errors, this is what a graphical application does with almost all errors, and this is what a website does with almost all errors. So while it would be great to try to sell someone on using panic, as in reality almost all errors in their program should be using panic, that means that all those errors have to, specifically at the point of the error or very near to it, be translated all the way down to a useless string... this will remain in the code for maybe a day before you sigh and get angry at how rigid your error reporting is and in the process of fixing it demand 1) more structured context or 2) the ability to annotate the error with more context at a few key places on the call stack.

To do either of these things in Rust requires that you switch to the painfully verbose (and unfortunately slow!) case-based error handling mechanism, which then forces you to throw down unwrap calls and try! expansions everywhere in your program even if you have very little logic that is even capable of failing in any normal sense, as error propagation in Rust in manual :/. I would love to use panic in my website or tool, and "omg this failed in a way I can't recover" is absolutely the semantics I want for all of my errors, but as far as I've been able to see--even in code from Yehuda, who sadly moved to Portland, making it difficult for me to sit down with him at a whiteboard for an hour :/--to be able to report (not handle: I don't want to handle panic, just report it) these errors in any reasonable way always leads to not being able to use panic, despite it being the more correct tool.

Zero-cost exceptions are occasionally required for performance, yes. They usually aren't--I think the strongest argument for them is in parsers, where you may be performing tons of I/O that could potentially error and don't want to bloat the icache with result handling. Either way, for two reasons (performance, and making sure you can catch exceptions at C FFI boundaries) Rust provides a `catch` in unsafe code. What it discourages is using them for semantic reasons.

I wish you would be more realistic about the tradeoffs of exceptions, though. The win in compile time alone from not having landing pads everywhere is substantial, and the "error handling boilerplate" you discuss isn't generally agreed to be boilerplate.

A big argument for using systems programming languages is thay they are fast: you are writing code that is compiled once and run thousands of times per second on millions of computers. Why would I care so much about compile-time performance? If I need a faster compiler mode during development (though in my experience, the pain of C++ compile times is due to its muti-stage transformation and lack of separate compilation for templates, not its exception handling... I don't find my projects that turn off exceptions to compile much faster), the compiler can also implement a really slow mechanism for exceptions as an alternative.

I also maintain that requiring the developer to do manual error propagation to get errors from the point of failure to the point of reporting to the administrator or the operator (which is what happens to almost all errors, whether you are writing a command line tool, a graphical application, or a website) is "boilerplate". At the simplest, without changing the error model, littering the code with calls to try! that push the error upwards is automatable (and I have a friend working on a compiler plugin to accomplish exactly that).

An example: I like statically-typed languages, but as demonstrated by languages with type infererence, having to declare every type every time it is used is "boilerplate", especially if types are long and unwieldy. C++98 has typedef, which lets me take C++'s long and unwieldy type definitions and make them shorter. If you are used to typing them out manually, every single time, some might even claim this is "ergonomic". However, C++11's auto is much better, and as demonstrated by languages like OCaml and Haskell even that isn't as good as it can get. C and Go have long and unwieldy error propagation (checking flags and manually returning new ones). Rust provides macros and tooling for this that make it safer (no more "goto fail;" or "Rage Against the Cage" exploits) and easier (like typedef!), but that doesn't mean it isn't still "boilerplate".

I mean, sure. But I've personally benchmarked a lot of code that uses Result and noted where it caused performance issues, if it did, fixed the code so it didn't anymore, and moved on with my life. Most of the time, it wasn't even close to being a bottleneck--most of the time the branch is correctly predicted and the time is just spent copying bytes for the `Ok` value, which is basically a nonissue if you can keep your error word-sized unless you're calling a tiny function in a tight loop that LLVM can't inline for some reason. OTOH, landing pad generation in Rust probably doubles its compile time, which is already pretty slow (which is one reason I personally will probably just compile with panic! -> abort, when that option becomes available).

I don't consider the error handling boilerplate because I do frequently want to recover, even from supposedly fatal errors. For example, if I'm handling an iterator of things, and some of them fail, I still usually want to keep processing them before I return the error. Exceptions lock you into a very rigid pattern of error reporting that make that much more difficult to deal with. Because libraries don't assume that I want to fail when they do, it can be easy and fast for me to do this, even for pathological inputs; that wouldn't be the case if everyone used exceptions.

I agree with you that Rust could do better at providing options for error reporting with panic. I believe there's an RFC about that right now, please comment on it!

I have been a games developer in a past life (my primary focus for over three years), and I am unconvinced I or any of the other people I worked with would have been willing to tolerate a low-grade performance degradation distributed around all of our code if we had access to programming languages that did not have that issue and weren't infinitely worse (and while I really wish I could use Rust, it just isn't infinitely better in a way that seems relevant for either the hardcore or casual gaming markets). Also, it sounds like there is something wrong with the Rust compiler if this landing pad generation really doubles the compile time... a poor compiler should not influence the language design in such a negative direction.

Solving problems like your iterator issue should not be difficult with exceptions: in fact, frankly, I don't see why it is any harder than with Result: your worst case is that you start with a primitive, "antitry!" (which should be called "try!", as it makes more sense than what "try!" currently does for that word) which performs an operation and returns a Result of either its value or its failure. Even if you do this "frequently", I would be shocked if this was remotely as common as the code that was assuming success and just wanted to fail if something fails. And, as long as you aren't trying to "handle" those errors (and it doesn't sound like you are, you just kind of want to fail out with a list of failure reasons) there is no semantic complexity either. Exceptions are the flexible primitive, not Result: simulating Result from exceptions requires a tiny finite amount of code, while simulating exceptions using Result requires modifications to an arbitrarily large amount of code.

As for fixing panic, what really sucks is that so much library code is going to be written using Result now when much of it should have been written with panic, both in the core library and from third-party developers, meaning that the boilerplate is going to be somewhat inescapable at the lowest levels of the program... I think the thing I like most about programming in Python vs C++ is that I don't have to wrap every single API I use to make it handle errors in a sane way. I don't think that fixing panic at some point in the future is going to work as there seems to be such awkward community momentum against exceptions and behind Result, when the real RFC needs to be "when you write your library, try to use panic, not Result".

> Also, it sounds like there is something wrong with the Rust compiler if this landing pad generation really doubles the compile time... a poor compiler should not influence the language design in such a negative direction.

Um, actual, non-trollish question: do you know how exceptions are implemented? Because I can't think of a way around this in a language with destructors, short of some sort of "doesn't throw" effect (which Rust doesn't currently have) or aborting on every exception. Do you have any pointers? Similarly, I don't understand how your "antitry" solution would be efficient on pathological input--"zero-cost" exceptions are far from that when the exceptions actually happen (and can be made to happen by malicious users). You also haven't addressed how I'm supposed to know to use antitry in the first place, which is one of my biggest issues with unchecked exceptions--again, the only alternative I see is a "throws" effect. All of these are language level concerns, not implementation-level ones.

> Exceptions are the flexible primitive, not Result

Catchable exceptions require coding transactionally if you want to use them everywhere and maintain strong exception safey. There's an enormous cost associated with that too; and worse, it can't be checked by the compiler.

Again: I have actually benchmarked a lot of code that uses Result, explicitly checking to see if it was a performance issue. It's almost never a performance issue. So performance-related arguments for why exceptions should be used everywhere are going to fall on deaf ears here. I am far more interested in seeing whether we can eliminate panics altogether for most of the common cases (e.g. with compile-time checked range types).

> C's error handling is expensive (in addition to being verbose and unsafe, Rust sadly only trying to work on the latter)

Did you read the OP? I realize the post is long, but the short story is that error handling in Rust can be concise and ergonomic. It's only verbose if you're doing explicit case analysis every where. I've found error handling in Rust to be the exact opposite of frustrating. It's pleasant and explicit.

I consider having to unwrap or try! on essentially every function call to be verbose. I did not read all of the text, but I did look at all of the code examples, as I was hoping this was an article about how to do it better than Rust seems to consider idiomatic, but was disappointed when even the examples at the end didn't seem to have any "magic". I then scrolled back to the table of contents and realized "oh, this is just a manual". Can you point to somewhere in the documentation where it shows error propagation (which is the key use case, not "handling") being as easy as it can be in C++ or Python? FWIW, "implicit, but correct" should be the goal, not "explicit" (in the same way that types should be inferred when possible, not manually specified: a world where obvious things must always be explicit leads to Java).

It will never be as easy as in Python because Python uses unchecked exceptions. (Frankly, I hate error handling in Python.)

I don't know Java or C++, so I can't help you there.

> I consider having to unwrap or try! on essentially every function call

They aren't on every function call. Only on functions that can return errors. The type signatures will tell you which.

> to be verbose.

I don't. In fact, I love how errors are handled. It's explicit, concise and ergonomic. We'll just have to disagree, I guess.

I also hate error "handling" in Python, but I thankfully long ago realized that what I want is error propagation and reporting", and almost all of my use cases for "handling" errors were mistakes: what I wanted was a mechanism similar to panic that could propagate rich error context (as opposed to just strings), and that is what unchecked exceptions are. Most of my Python code that tried to "handle" errors now gets removed and replaced with better semantics: the kind of failure semantics that one might expect to get from panic, but can't, as panic loses too much context to be useful for reporting (forcing developers to use case logic).

Rust programs are littered with calls to unwrap and expansions of try! for the sole purpose of doing manual error propagation, which is both verbose in the code and slow at runtime (as the successful case must constantly produce and then check error results), just so the error can get to the top level somewhere and be reported to someone (which in turn drags a surprisingly large amount of your code into the domain of "functions that can return errors"). None of that boilerplate should be required: even with an insistence on the mechanism, it is such a clear case of boilerplate that a friend of mine finally ended up working on a compiler plug-in whose purpose was to jusy add calls to try! around anything that seemed to require those calls.

I like explicit error handling. I don't want errors bubbling up automatically.

As I said, we'll just have to disagree.

Clearly ;P. I just hope you realize that you sound a lot like the people working in languages like C or Java or Go that insist that adding abstraction and automation is bad as they want everything to be explicit and transparent :(.

That's absurd. I wrote the OP, and the entire article is about using abstraction to make error handling more convenient. Here's an excerpt from my post that describes my true feelings on the matter (because we don't all fit nice and neatly into pre-conceived buckets):

> My advice boils down to this: use good judgment. There’s a reason why the words “never do X” or “Y is considered harmful” don’t appear in my writing. There are trade offs to all things, and it is up to you as the programmer to determine what is acceptable for your use cases. My goal is only to help you evaluate trade offs as accurately as possible.

Maybe this is going to be "way too Hacker News", but to me this is "bulb paradox": C developers could claim it is absurd to say their arguments for explicit and transparent logic are somehow against abstraction and automation because they, unlike their assembly brethren, opted for structured control flow and rigid function conventions, and Java developers can say the same about the way they abstracted explicit polymorphism. That doesn't change the form of the argument they are making about going even further.

Having to litter code with unwrap and try! just because somewhere much lower an error is used and much higher an error is reported does not seem beneficial unless the alternative is to do it in a way that is even more manual and less safe, but that's not how it works in the languages I use on a daily basis. Yes: C and Go make dealing with errors so painful and dangerous that Rust is absolutely amazing in comparison... but I don't program in C or Go and I would hope we aren't using them as the benchmark when we have C++.

I encourage you to read my example with type declaration that I wrote elsewhere in this thread.

https://news.ycombinator.com/item?id=9552612

Recognizing trade offs is not the same as the blub paradox. Note that I responded that way because you literally accused me of not liking abstraction at all: "you sound a lot like the people working in languages like C or Java or Go that insist that adding abstraction and automation is bad as they want everything to be explicit and transparent." If you have a more nuanced argument to make, then do so, but I'm not going to let you paint me into a box.

See pcwalton's comments in this thread on exceptions.

Read that quote again: I say "add" because I mean it; I would never argue that a C developer does not like abstraction at all because that is obviously false (functions, control flow, text macros). You can't say that I "literally" said you don't like abstraction at all, as that's not what I am arguing: if anything, I am arguing that, due to the blub paradox, seeing the difference between the automation you encourage and the automation you have a distaste for is complex at best and impossible at worst; I look at your article and, as I have every other time I have examined Rust, am left wanting for more abstraction and automation when it comes to errors.

Your argument that you do not want error propagation to be implicit is strange to me, as a developer who is used to this being automatic, because it is does not affect safety to automate and is effectively nothing but boilerplate. There is nothing different in the form of your argument against exceptions from the form of the arguments made by developers of C or Go or Java against adding features like templates or optionals or macros. It isn't that Java developers hate abstraction in all forms (that would be an absurd argument that I would need to pull from an AbsurdArgumentFactory ;P), it is that the form of argument that we often hear from all of these developers about the features we like in languages like C++ or Rust or D has the same core structure :(.

On pcwalton's notes on exceptions, I already responded to him in my comment that started my involvement in this thread, and went further in my first reply this morning: his mental model seems stuck in the implementation of exceptions as defined by Java and as used by Java developers. His datapoint for why they are so slow is from an old story about gcj: the Java exception model requires a stacktrace reification, and you would not be able to replicate that kind of performance loss in C++, even though they share the same implementation of propagation. His API issues are all (as argued by others) based on the awkward way that Java developers have made exceptions used for things that aren't really errors.

Have you developed in Erlang? This is a language that considers errors and failures to be the core problem faced by developers, and which has structured almost all other decisions surrounding that core premise. After spending a lot of time coding in Erlang a few years ago, it fundamentally changed the way I think about errors, and that was after over 20 years of software development in languages like C++ and Java. When I was (comparatively) green and naive, back in 2001, I even made an argument for checked exceptions to Microsoft in C# (it was partly my argument for RAII in that same thread that got us the using syntax sugar for IDisposable): that is how far I had to come in the subsequent decade.

Erlang has the right abstraction: a mechanism for exceptions that is designed somewhat similarly to panic, in that it encourages you to structure your code in ways that isolate failures behind processes and avoid ever "handling" errors, but which lets you propagate and augment rich error context through multiple process layers implicitly, making error propgation automatic and without boilerplate. Once you "get it", you can do this easily in any language that has unchecked exceptions (even Java, using RuntimeException as the new exception root, but you have to really hate Java to pull his off ;P), as function calls can be mentally modeled as calls through process linkages (though you sadly then can't use the standard libraries provided by any of these languages, as they are all built with a broken model :().

Given how many other amazing things that Rust got uniquely right, it is somewhere between disappointing and devastating that error propagation, something which is so important, only seems to be competing with languages (like C, Go, or Java) where errors are almost unworkable :(.

> Have you developed in Erlang?

Yes.

> Erlang has the right abstraction

There is no right abstraction. If we can't minimally agree that there are trade offs at play here, then we can't have a productive conversation.

> and avoid ever "handling" errors

I want to explicitly handle my errors.

Just because you had great internal progress does not mean you arrived at some objectively correct solution. It obviously works well for you, but everyone is not you and not everyone has the same requirements or preferences as you.

The arrow I am providing for progress is one towards abstraction and automation; so, fine: we are right back to where we were before, with you making an argument that is of the exact same form as those people from C, Go, and Java who argue against adding abstraction and automation to keep things explicit and transparent, the people you were so painfully opposed to being lumped together with, and you seem to have exactly as little concrete rational as they do for making that "tradeoff". It isn't clear there is any tradeoff in play here, and you haven't tried to demonstrate one.

My argument is "given that there is absolutely no demonstrated benefit to doing so, and even some clear downsides (performance of normal successful code), being forced to litter my code with tons of boilerplate--something you can clearly see if you glance almost anywhere in the code for Cargo--is a major and depressing step backwards". Your argument seems to still be "I don't want that much automation, I like things being explicit, and of course you should look again the comments from pcwalton you already responded to that complain about Java (really just Java) being slow"... :/.

Explicitness has benefits.

Honestly, please just leave me alone and stop twisting my words. We can't even agree that there are trade offs involved here. There's no point in continuing.