Hacker News Reader

In my opinion, this is not an issue with exception handling. It's an issue with bad programmers.

You can dumb it down as much as you want, people are still going to screw it up.

And you have exactly the same issue with "classical" error handling: you have to undo the partial job. Here's a bit of C code I wrote just this morning which closely ressembles your example:

    for (i = 0; i < pdata->overlay_nr; i++)
        if ((ret = overlay_init(data, i))) {
            while (i--)
                overlay_destroy(data, i);
            goto overlay_err;
        }

No exceptions, but I still have to remember to clean up before I dispatch the error.

I use exception quite a bit in C++, but it does fit my coding style. I use RAII almost exclusively, which alleviates most of the issues. That means that I don't have try{}catches everywhere, mostly only when I want to do actual error handling.

Exceptions are a tool, it's up to you to use it correctly (or not use it).

Complex logic isn't going to be easy no matter how you structure it because the problem in question is intrinsically hard. The real question is whether exceptions are harder or easier to write or understand than the alternatives.

Your example illustrates this nicely: say you jumped on the ideological bandwagon and decided that exceptions are evil and must be avoided. How does this change your code? You can try C / golang style where errors must explicitly be checked & routed through normal flow control - something like this has a million variants floating around:

    var recover = 0

    for (var idx = 0; idx < xs.length; idx++)
      err = xs[idx].update()
      if err:
          recover = 1
          break
    }
    if recover > 0:
      // TODO: hard part goes here

In either case, all you're talking about are minor semantics (i.e. whether you have to explicitly code an if statement, use a flag or goto, etc.). The actual hard problem is what meaningfully can be done for recovery and conflating that with the mechanics of how you reach that code isn't particularly interesting.

"ideological bandwagon" is precisely correct.

It's people blaming their golf clubs for not being good enough, when the real problem is they need to learn to swing properly.

How would you write this without exception handling, how would that make it any easier? Perhaps do not put the entire loop in the try catch, but just the single iteration.

Oh no. I'm not saying it would be easier without exceptions. I'm just saying that the current status of our programming tools makes writing safe code very hard, and exceptions are one more thing you have to think about. I use them a lot...

The authors of the paper propose their "worlds" API as a way to make writing safe code easier. They're still using exceptions, but they would require no cleanup...

The code becomes:

  try {
      in thisWorld.sprout() {
          for (var idx = 0; idx < xs.length; idx++)
            xs[idx].update();
          
          thisWorld.commit();
      }
  } catch (e) {
      // no clean-up required!
  }

So it's commit for data structures for data structures. If an exception is thrown and the commit line is not executed, no changes will be visible.

> This is like saying... be sure to never copy more bytes than the buffer capacity. Easier said than done.

A solved problem except when people insist on using approaches where it's not a solved problem? I couldn't agree more! :-)

firstly, the update example is a bait and switch. Partially updating an array is not inconsistent. It may be wrong depending on what the contract of the function says but that's but the same as inconsistent.

Indeed the example that prompted this article back when I wrote it many moons ago was a case where you wouldn't want the state restored

> In general, however, this is not sufﬁcient since update may also have modiﬁed global variables and other objects on the heap

"Doctor! It hurts when I do this!" "Well don't do that then"

It's hard to write any correct code when you're mutating globals and arguments all over the place. Exceptions can certainly make this worse.

In general if you're not using globals or mutating your arguments this isn't a hard problem. If you are mutating arguments and you want to ensure a "restore all state if an exception is thrown behaviour then yes this is sometimes hard (unless your argument supports a rollback mechanism - e.g. it's a database) but I submit that a large part of why you haven't seen that is that it's a contract people don't care enough about to support

Yes, that's not exception safe. Writing this error safe without exceptions requires nearly identical discipline. How much non-exception code have you seen checking every return value and restoring state? There are alternative more safe ways of writing this, but none have to do with whether exceptions were used.

This is a case where the developer needs to know that all update calls may not be completed. This may be a high or low probability, and may have fatal or no consequence. How many programs can handle a hard drive crashing or CPU glitch? Writing good error handling requires a lot more than removing exceptions, and often is not worth the cost. No software handles every error condition.