I disagree. Throw keyword is the greatest invention, and makes programming so much better. Error codes are the evil. Exceptions allow to separate business logic from error handing in a most effective manner. Author likely have not ever worked on large codebases where the error handling was messed up beyond any repair due to having to pass error codes every friggin where
<p><pre><code> only the language runtime and operating system
would be allowed to raise exceptions
</code></pre>
So you still need all the exception machinery, but "normal" code can't use it? Seems like a terrible situation.<p>Also, who's in charge of deciding what's "language runtime" and what isn't?
> The Year Everything Crashed<p>Which year?<p>> If you were using computers in the years that followed you remember the time well even if you didn’t know the reason; a lot of software that had been stable and solid before started crashing and misbehaving.<p>I think I missed this.
Throw in Java is very inexpensive. Expensive part is creating new instance of exception, which figures out stack trace and creates bunch of immutable strings.<p>There is a technique of throwing existing static instance of exception, which generates no garbage and two orders of magnitude faster than traditional java approach:<p><a href="https://github.com/questdb/questdb/blob/7560895ee400c82b0e5e39440eaf6c55bbbb7d7d/core/src/main/java/io/questdb/cutlass/text/types/InputFormatConfiguration.java#L207" rel="nofollow">https://github.com/questdb/questdb/blob/7560895ee400c82b0e5e...</a><p>The only downside is that stack trace is effectively defunct.
I love the way Elixir/Erlang handles this, personally.<p>If the error is expected/should be handled, just add the error to your pattern match and handle it right there (or bubble it up, if appropriate).<p>Truly exceptional situations where something "should never happen" won't be pattern matched against, BEAM will crash the process, and your supervisor will get you back to a good state.<p>Feels so much cleaner than either exceptions everywhere or easy-to-ignore error values.
I strongly believe that the Go approach is the correct way to go. Every function that can fail should return an error code and then the programmer invoking said function is expected to handle the error code. It also used to be that way back in the old C / C++ days before SEH made it messy like Java.<p>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. So then random error conditions sprinkled throughout business logic go back from "this is how Java is done" to "this is a code smell".
I worked at a telecom company. They had a program written in java for generating the initial customer configuration.<p>Among other stuff it used exceptions as control flow and it made me make extraordinarily high estimations for seemingly simple changes.<p>Anyway, I don't think I agree with the article - it's again the matter of the knife and how you use it.
We've moved past it now with having errors just be part of the type and signature so you can use language tools to deal with them like any other type instead of having special syntax. I like that. It allows you to express certain concepts more easily. For instance, "in case of failure, use blank" looks nicer in Rust than in Java, and so you're more likely to use it. Java is also sort of moving this way because checked-exception methods don't play well with Streams syntactically.
> <i>Structured Exception Handling (SEH) was born.</i><p>This, including the abbreviation, is the name of a feature of the Windows API.<p>The author is confused between exception handling in programming languages, and exception handling in the MS Windows operating system.<p><a href="https://docs.microsoft.com/en-us/windows/win32/debug/about-structured-exception-handling" rel="nofollow">https://docs.microsoft.com/en-us/windows/win32/debug/about-s...</a><p><a href="https://en.wikipedia.org/wiki/Microsoft-specific_exception_handling_mechanisms#SEH" rel="nofollow">https://en.wikipedia.org/wiki/Microsoft-specific_exception_h...</a><p>Note that in Microsoft C++, this uses special <i>__try</i>, <i>__except</i> and <i>__finally</i> keywords, which use underscores because they are extensions, separate from the ISO C++ <i>try</i> and <i>catch</i>.<p>SEH can catch events like access violations. It's more like Common Lisp exception handling in that you can catch errors without any stack unwinding taking place, so that fixing up a fault and re-starting an instruction is possible (like catching a SIGSEGV or SIGBUS on POSIX).
Error propagation is must have for any project. You always need to handle some errors in parent context because local knowledge can be not enough. And you can choose between manual passing of error codes (c, go, mundane and boiler-platy), algebraic errors (rust, zig, optional sugar can make it convenient and look like SEH) and SEH. Yes it is additional condition flow, but you have to introduce it in some way.
Didn’t Java require all exceptions be declared in the method signature? (Haven’t used it in years.)<p>I think that’s the best solution. You declare what error conditions could arise, but not using magic numbers. The caller can then decide whether to handle them or pass them to its caller etc.<p>I agree that unexpected exceptions (like it’s possible in C# and possibly others, you can just throw whatever whenever) are far from optimal.
The problem comes when programmers muddle and get confused about different possible "failure/error" conditions in a program.<p>A) Bugs, i.e. errors made by the programmers of the software
B) Expected logical conditions that only appear as "errors" to the <i>users</i>
C) Unexpected failures such as resource allocation failures<p>Let's have a look at these one by one.<p>Case A, i.e. bugs written by programmer, i.e. the program is about to violate it's own constraints/logic/pre/postconditions/invariants. Examples are many, but for example off by one, accessing nullptr/null object, array out of bounds etc. Really the best way to deal with these is to abort/panic/dump core with a loud bang and produce a core dump and a stack trace to simplify debugging.<p>Case B, i.e. conditions that the application should expect to encounter and be prepared to deal with. For example your TCP socket connection times out, DNS query fails, HTTP query response returns 404. In any such case when you need to write some logic such as "retry to open the sockect connection" or "tell the user that the resource was not foudn" or try to resolve DNS query again later the best method is to use some kind of error enum/number/code kind of system. And to recap the "errors" in this category are not errors for the software but only errors for the <i>user</i>. I.e. for the software these are just logical conditions.<p>Finally Case C), errors that are neither A or B. Typically these are just some very unexpected conditions such as resource allocation failures. Your program failed to allocate a socket or pipe or a mutex or whatever. Should not happen but <i>might</i> happen once in a blue moon under heavy system load or unexpected conditions. These are the things you don't want to conflate with your logical "error condition" path from case B because't that won't scale and propagation of errors up the stack becomes very tedious. These are best suited for exceptions.<p>Edit: Note that this isn't a static state but what is considered a bug or a logical error <i>can</i> change across modules depending on the software project organization. A module written by another team migth consider illegal arguments as "Logical error conditionds" and return error codes, whileas a similar module written and used within a single team might just consider this a bug and dump core.
> Dealing with them in a more elegant way than inelegantly crashing goes all the way back to 1962 in a near-forgotten language called LISP.<p>Even as someone who isn't a Lisp programmer, I find the idea that Lisp is a "near forgotten language" to be a bit of a stretch.
I agree that `throw` is easy to misuse; but I think this is a symptom of something else, namely in architectures where input even handler code is spread all around or, worse yet, dynamic. This is really common in many languages, and perhaps my greatest pet peeve.<p>However, throw is a wonderful facility if your architecture has one defined entry point for inputs of all kinds. It means your outermost loop can have a try block, and literally everything else can feel free to throw in the safety and comfort of knowing the entire program won't fall down.
Can someone point me to a code example (preferably TypeScript or JS) to clarify what the author proposes as an alternative to ‘throw’? Maybe it’s Stockholm Syndrome, but I’m struggling to picture how returning an error code (and checking it with an if-statement after every function call) would make code easier for a human to analyse. Seems like it would just make it a lot noisier and less expressive. But I’m intrigued.
The keyword, and exceptions, are orthogonal concepts that this post is conflating. The real issue this post has is with exceptions (and in particular user-defined exceptions, though I'm not really sure why this matters because you can always (ab)use system exceptions if you have a way to reliably trigger them). You can still use the `throw` keyword with other error-handling models, such as with Swift's Errors.
Could some sort of hybrid approach be an improvement? What if we required every function to explicitly declare the types of exceptions it might throw? The compiler could enforce it and make it transitive to higher level functions.
When 'pair programming' was chucked in as an example of one of the worst things that happened to programming I lost interest.<p>Back up your assertions with facts. If you don't have facts use good truthful examples.<p>Too much opinion and conjecture isn't useful.