The Throw Keyword Was a Mistake

The opposite to exceptions isn't (necessarily) error codes. Golang errors are a recent example.

I do not think that these 2 extremes are the only options. You can look at Erlang's error handling for an example that both simple and easy to use, yet provides the right amount of information. You do not need to pass error codes either. I usually have a structure that is not too deep and at the bottom there are more specific errors that can be logged very close to the codebase where the error happened and propagate only error or ok to the caller. Even with large codebases this is pretty manageable.

I would say that the beauty of error codes is precisely that it is an evil that is easily visible, whereas exceptions lurk in the shadows.

Error codes are like someone suggesting "lets blow this thing up" and you can either follow their advice or ignore it.

Exceptions are more like someone throwing you an unlocked grenade. Unless you expect them to be that irresponsible and unless you actively react to their behavior, things explode.

I once had to debug an issue with a Java app that did not throw exceptions anywhere, but it did use the Hibernate ERM framework and somewhere deep inside Hibernate there was a bytecode patching library used which didn't like our custom build of the VM and produce a class-less unchecked exception which would crash the app.

And in my experience, the people that do bad error handling with return codes are also the same people that catch an Exception and rethrow it wrapped in a RuntimeException to remove all that try/catch bloat. It's laziness in either case.

And the performance argument is moot. Yeah don’t use exceptions in a tight loop, but as its very name suggests, this is to handle a hopefully rare branch of the code.

> who's in charge of deciding what's "language runtime" and what isn't?

Maybe the people who define the language? Who implement and package its standard compilers/interpreters? This is not confusing outside the world of empty rhetoric.

This is how it's done in Rust. panic macro unwinds stack for tracebacks, there's std::panic::catch_unwind, but panic can be compiled to be aborts to do away with stack unwinding, error handling is meant to be done with Result<T, E> type, whereas panic is meant for unrecoverable errors

It's not really about who can use it, but rather what it is used for - language runtime can't use it for anything they want. So if a systems-level feature of the language is supported in part by runtime code, that's a place where this may happen, e.g. the Go Runtime throwing a stack overflow.

Of course the counterpoint is that C++ and to some extent Java are designed for allowing user code to create system-level facilities, so we're back to the land of "please don't misuse exceptions."

Well lp0 would catch fire, but it wasn't as bad as using throw!

You may believe that of course, but the reality is that we have no proof either way. I personally believe the opposite, that Go-style explicit manual error handling obscures both the business logic and the error handling logic, and makes it much harder to read code. Unfortunately, we don't have any studies that could shine a light either way, and it is very likely that if we did, we would see something similar to the typical static-vs-dynamic typing study : no real effect on defect rate; no way to accurately measure productivity.

> And the beauty of using statically typed languages with error code return values is that one can use automated tools to find all the places where error codes are being ignored.

Even better, the beauty of garbage-collected languages with exceptions support is that errors can't be ignored at all! And if you don't have garbage collection and need to manually cleanup every resource, both approaches get a lot more difficult, and it's much harder to tell which ends up being superior.

>Every function that can fail should return an error code

Every function that can fail, that can take invalid arguments, or can be called at invalid times. Which widens the set to basically every function. Old APIs had a convention to always return a status directly and results in out-params, except for pure mathematical operations (in which errors were mostly ignored, e.g. in a computer, a+b may fail as much as fopen(), but who cares).

Observing this fact, one can free themselves from:

  if ((status=operation(args, &vague_error_descriptor))
    return status;

and handle the specific error event where it seems reasonable in the way that seems reasonable.

Unwinding call stack by hand doesn’t automagically handle errors. At main() or at the other high-level call site you still have no idea what to do with an unexpected error except logging/presenting it and exiting (or continuing in hope invariants were not broken).

>one can use automated tools to find all the places where error codes are being ignored

The same is true for exceptions - every milestone like db.open(), file.save() and process.spawn() should be try-catched. And in both cases you don’t know which errors “codes” are still unhandled.

A few more steps and you'd have reinvented functional programming.

I do not now how many hours was wasted on trying to debug Java applications that did not have this principle and produced 10000s of lines of stack traces in production with cryptic exceptions.

> one can use automated tools to find all the places where error codes are being ignored

What I want is an automated tool to display the 1/3 of code doing useful work, and hide the 2/3 useless noise that should have been generated. We shouldn't make human beings read exception bubbling boilerplate for the same reason we don't make them read stack frame setup boilerplate.

The old C way was returning an error indicator and providing the error code in the global variable errno(), which has ... issues.

> it's again the matter of the knife and how you use it.

The author makes this point repeatedly: exceptions would be great if all programmers were above average, but (of course) they're not. In practice the knife is juggled and thrown (heh) and generally mishandled so much that the floor is covered in blood. This gets us into pg's whole "blub" design-for-geniuses vs. design-for-idiots discussion, with is basically dueling strawmen, so I'll bow out there.

I feel like with errors we're always in a state of sin because the way errors create a combinational explosion of code paths.

The only thing I have to say is I have a distaste for throwing exceptions across API boundaries.

Initially yes, but this is somewhat unpopular these days as it means you have to daisy chain a new exception all the way up the stack if you can't handle it locally.

Most have switched to runtime exceptions, which are more flexible in that regard.

No. Only a certain subset, known as “checked exceptions” (as opposed to “runtime” exceptions), need to be in the signature.

In what may come as a surprise, checked exceptions are actually frowned upon in modern java (e.g. new stdlib apis tend to avoid them). They do not compose very well with the rest of the type system (e.g. you cannot write a ”map” function that is polymorphic over checked exception types)—or at the very least, do not compose as well as some other patterns, like Optionals

Checked exceptions sound good on paper. In practice I think I re-threw every checked exception as unchecked.

In retrospect I feel like 'handling' exceptions is a myth. If you knew how to handle them, they wouldn't be exceptional.

Agreed. Exceptions should be, well, exceptional. Not normal parts of control flow, or commonly occurring kinds of errors. Assertion failures, or other things that would otherwise send a signal and terminate the process - seg fault, divide by zero, etc. Maybe something like a socket being closed unexpectedly. That's kind of the boundary where it's worth debating. Anything more common/expected than that should be represented as an error code and not completely redirect the program's control flow.

goes on to explain misuse.. jk sort of.

What when allocation fails or disk full etc?

That was the basic premise of checked exceptions in Java.

It's not really related to the type system or anything. The root of the problem is Java compiles each class as an independent module, so any method has to deal with all its exceptions, even if only naming them, or it can't compile. Thus checked exceptions meant you either got huge signatures, or you wound up wrapping them all into other exceptions, which then made them much harder to inspect.

And unchecked exceptions made the problem worse. Java uses single-inheritance and put unchecked exceptions on their own branch. This meant you wound up with, for example, IOException and UncheckedIOException with no close common ancestor, so you had to wrap one in the other. So now, in addition to complicated signatures, you are doing more wrapping.

I think what might work would be to ditch the checked / unchecked idea, mostly. (You still want to treat errors like division by zero or invalid array indexing as unchecked.)

What you distinguish instead is whether methods are "safe" or "unsafe". An unsafe method can still catch some exceptions, it just doesn't promise to catch all of them.

The safe method must catch everything. For example, your main method and Thread.run would have to be safe.

Except for the transitive part, this is what Java does. But it's doesn't address the complaints of the article, which is bothered by the non - local control flow and the large cost of the exception machinery in C++, and by the poor interaction between manual memory management and exceptions.

Note: I think the article is vastly exaggerated, and completely wrong, at least when looking at managed memory languages.

This really reads like an article by someone who likes to think they know better than everyone else, while liking things that the industry has tried and moved away from.

I would much prefer a similar sounding article from someone who champions some weird technology, like people APL people who advocate for extreme conciseness of code, or Forth people who advocate for extreme integration of solutions. I don't think they're right, but at least they would be novel and would advocate for something we haven't moved away from as an industry for a reason.

Rejecting the entire main argument because of a single aside - a matter of style more than substance - is effectively argumentum ad hominem. Yes, the author comes across as a grumpy old "get off my lawn" type (like me in fact). No, that doesn't make any of their arguments or anecdotes about throw invalid. Try addressing the issue, not the person.

No, article corresponds to unicorn-rainbow-coin-rebel style of most hackernoon content very well.

Which by the way was bullied away for no reason. goto has it's uses, but nobody would dare to use it even when it's appropriate

All control flow are jumps underneath it all. The only important question about a particular control flow syntax element is: does it allow a human to reason about a particular code scenario more easily.

Most of the time, I think exceptions help more than hurt. Like many things in language design, it is a trade off, in this case of concision vs simplicity.

Worse, the very same people who sneer at "goto" even when used in a very controlled fashion (e.g. the cleanup-cascade pattern common in kernel code) will turn around and sprinkle their code with a construct that's basically a non-local goto with an unknown (at compile time) destination. They complain about "spaghetti code" and then create code like a toddler's attempt at macrame. Defending exceptions in non-exceptional cases is usually an exercise in hypocrisy.