Isaacs: try/catch is an anti-pattern

  my_parser(String, Output) :-

    parseJSON(String, JSON),

    extract_the_values_I_want(JSON, Output).

 if my_parser(String, Output) then

  ...do stuff with Output...

 else

  ...show user "couldn't parse" message...

- returns the error message and context instead of just error code

- wraps the internal problem properly inside its own error description and context

- cleans up all internal state

Guess what... that's exactly what exceptions do. If don't do the first point, you'll end up with multiple causes producing the same error number. If you don't do the second, you'll get "invalid data" when parsing json (where? what data? which line? which element? why is it invalid?). If you don't do the third, you're going to crash anyway.

So if you don't use exceptions to make your code nicer, you're going to end up implementing the same flow over and over again in places that could just allow the exception to pass through. You might even write some helper/macros functions to... add a file and line number when wrapping previous exception. It feels like reinventing the wheel.

Edit: Forgot to mentioned the collection processing in the end. What is tricky about it is that for a common "map()" to stop on error, you'll need to have a common way of handling errors. Exceptions do this just fine, custom methods - not necessarily.

The author's point of view seems to be pretty Javascript/Node.js -centric. I can relate. try/catch and node.js -style asynchronous coding do not work together. However, I'd say that it's the async programming model that is broken, not try/catch.

Writing code in node.js async style is very difficult for humans to do (at least for me), but compilers are excellent in this type of program transformations (continuation passing style). The Haskell and Erlang compilers and runtimes do this automatically. You write regular imperative code but it's executed in an asynchronous manner using co-operative fibers (maybe together with native os threads).

A similar solution is possible with an interpreted language that has some kind of continuations. Every blocking system call could be translated to a co-operative fiber context switch using kqueue/epoll.

What is really baffling to me is that none of the popular interpreted languages (javascript, python, ruby) seem to have decent continuations. I don't know of a reason for not implementing continuations in an interpreter, is there any? Using continuations, one could implement pretty nice async operations and exception handling.

Using return values for error handling is really painful. I've been writing a system call heavy C program, and about 40% to 50% (in LOC) of the code is error handling. In test code coverage, I can reach just over 50% branch coverage as most error conditions don't happen while testing. I don't know of a nice way to make e.g. the network fail at the right time to test my error handling in that case.

C++ is pretty nice when it comes to error handling and exceptions as resources are cleaned up on error. Python's with..as statement or Haskell's Control.Exception.bracket can do the same thing (the latter is just a regular function, not a language builtin). In C, most error handling is required to free some memory you allocated earlier, but even in a garbage collected language you still have system resources you need to free (file handles, sockets, db connections etc).

I am probably one of those people who catches exceptions prematurely and who hasn't learned to use "finally." If you link to some advice on how to use such things, I'll read it. I want to believe that I can learn a better way to use exceptions, but they just haven't clicked for me.

Then again, I've been using exceptions in an environment (C#) that matches the author's JSON.parse() example very well. The .NET library designers already decided what counts as exceptional, and it's often not possible for me, as a .NET user, to decide much of anything about the use or placement of try/catch.

...when you're building real systems, the complexity of the error handling can approach or exceed the complexity of the "normal" path...

I can understand all too well that a complex error handling path is intimidating, tedious, distasteful, and no fun at all. But in every serious project I've been a part of, error and exception handling has been where the bulk of the design, implementation, and testing work was done. That stuff is precisely how serious systems distinguish themselves from toys. Having a catch-all crash-path doesn't change that, because the serious system is not permitted to crash. As the author here points out, that's what assert() has offered for decades anyway.

  {'a':1}.get('b',5)