Is try..catch really useful?

I feel like this assumes that the errors that might be thrown by a section of code are knowable. For some high level projects with poorly documented dependencies interacting with third party services that are in constant flux it’s nearly impossible to know everything that’s going to happen and try..catch allows you to program defensibly when an assumption the programmer made is invalidated.

I ended up making an account for this one. Exceptions are a section in one of my favourite blog entries:

http://blog.ploeh.dk/2015/04/13/less-is-more-language-featur...

Their argument is that Exceptions are GOTOs in disguise and point to the use of sum types.

I have found this to be good advice when using Java 8+. Composing Optional<?>, Either<?, Exception>, or CompletableFuture<?> has provided sufficient tooling for handling failure scenarios.

I also find that Exceptions slow down my reasoning about code, because they are side effects - see functional programming.

Should we have error handling at all ?

Software engineers: no, too much work to think about every possible error case

Sysadmins (looking at above statement): NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

Now in theory you could do error handling without try...catch. Golang especially espouses that vision. However, like C before it, in practice Go programs ignore pretty much every error case.

To that practical situation, I will say, try...catch is far, far superior. Why ? Because it terminates your application instead of running the program in a way that erases the database. As an additional bonus try...catch gives you exactly what happened, and the entire stacktrace that mostly specifies what all the parts of the application was doing (and if you know what you're doing in Java/C++, including all values of all internal data structures. In Python ... well a little bit less but still substantial information).

.then().catch() is basically just a fancy wrapper around try..catch, so I'm not entirely sure what the example is supposed to show?

With async that code would be equivalent to something like:

  try {
    const response = await fetch(...);
    const data = await response.json();

    if (data.errors) {
      handleErrors(data.errors.code);
    } else {
      handleResponse(data.response);
    }
  } catch (error) {
    error; // handle error
  }

First of all, the way of handling the errors really shouldn't depend on the size of the project. Nobody is ever going to rewrite their error handling just because the project grew up.

Second, and likely more important fact is that the server returning the non-4xx status code is not quite an exception. It is just one step away from your happy-path. The mechanism of exceptions should be used for things that you don't expect. Mostly because of the cost they imply on the runtime (at least for C++ and similar languages which do stack unwinding and not so much for Swift, which treats the exceptions as just a different returned value with almost zero runtime cost).

Every complaint about a goto is valid for try..catch, except it's worse because it's a non local goto for which the destination is unknown at compile time. Ugh. Yesterday I had to deal with a piece of code that relied on a certain exception to do a particular kind of repair, but someone had added a different exception twelve layers down (and across an RPC boundary). This was much harder to debug than it would have been with error returns, because nothing in those dozen intermediate layers had a chance to see and log the new exception. It just flew right by them, and when it arrived at its destination there was no information about its provenance. Thus, I had to go through a tedious process of instrumenting each layer to see how far it got before the flow of control was yanked away from it, which took hours instead of the minutes it would have taken to step through the same thing with error returns.

I know there are some techniques that could have made that experience better, but this kind of crap seems to happen every time I have to interact with a codebase that relies on exceptions as a primary error-handling mechanism. That means practically all C++ and Java where it's strongly idiomatic, and some Python where it's more weakly so. Error returns might be more verbose, but they're ultimately better for maintainability.

I would argue that reasoning about promise chains are difficult enough to where an abstraction is desirable.

If you asked me to identify the most maintainable and easy to read of these two pieces of code, I would say the answer is easy.

Promises:

  const p1, p2 = undefined;

  somePromise()
    .then((res) => {
      p1 = somePromise(res);
      return anotherPromiseFuncThatNeedsP1(p1);
    })
    .then((anotherPromiseRes) => {
      p2 = anotherPromiseRes;
      return p2;
    })
    .catch(e => {
      // log, throw etc. 
    });
  // done

vs

try/catch:

  try {
    const p1 = await somePromise();
    const p2 = await anotherPromiseFuncThatNeedsP1(p1);
    // done
  } catch(e) {
    // log, throw, etc.
  }

I generally am picky on my try/catch implementations... I use it way more often on the backend (PHP/laravel) than front. Though I will tap into then/catch on async functions which I guess is built-in try/catches.

On the backend I mostly do try/catch when I have a bunch of things tied together in a db transaction... If any part of the commit fails or anything errors at all the whole thing will rollback. Esp. handy when doing multiple relationship attaching in one go.

Also it comes in handy when dealing with API's and things, but for most scenarios it's not needed too often. But I also don't test every little thing, I believe moderation in all things including try, catch, testing. lol.

Unfortunately that web page cannot be fixed via "reader" mode in Safari.

But as I read it I felt there was an implicit "yes, but" running through it. To step up a level:

- unexpected problems occur - you have to manage them. - managing error return codes is tedious, and consumes a lot of lines of code, which is an opportunity for errors in and of itself.

Try/catch is a sign that something went wrong, but it allows you to manage sequence points (via catch) to deal with them. With unwind-protect (typically via automatic destructors in contemporary languages) most of the required boilerplate is automated. Yes, there are corner cases (e.g. the reason for C++'s make_shared) but there are many more when you're tracking error returns.

Now where I disagree right up front is that try/catch is not a way to "handle errors". It's a way to deal with them. We already have experience of using signalling to handle errors: the Common Lisp condition system allowed you to catch an error and restart the computation. It was a wonderful, general mechanism (even more general than just this case described here) and indeed, it was so general and so powerful that it also turned out to be an opportunity for incomprehensible code. We all learned from that, which is why nobody else has a facility for handling errors.

(BTW another great example of this kind of generality was method combinators. Sounds great but in practice: no thanks!)

Well, I have to say I am completely unpersuaded.

I think try catch is fine with some documentation or commenting around why the developer chose to do so instead of specific handling for all the different possible exceptions.

try..catch means you don't have to have perfect knowledge of what errors may be raised - which you simply do not have when dealing with external code. It also means that you can guarantee that no exceptional case has occurred that you have not handled. Either you explicitly deal with the issue or you have the option to fail & log.

Yes, error handling is really useful.