The author is consciously using exceptional with another accepted meaning of the word (rare). And you are (consciously or not) at the same time misunderstanding him and being condescending, while adding strictly nothing to the discussion.

Exceptions are often used to catch unanticipated situations but they are also, legitimately, used to simplify common case logic by moving special case logic elsewhere.

"Exceptional" and "unanticipated" are not synonymous.

Edit:

I would add that it is true that there is a semantic burden with exceptions in that they are suggestive of error, rather than special case, conditions. So I would be very wary of using them in that way simply in my own code because it will potentially be misleading to consumers of the source code.

But if the clarity of the remaining code is sufficiently enhanced then it's a fair trade-off.

h2s: Can you explain to us what exactly is the difference between the implementation of flow control during exception throwing and all the other kinds of flow control (including, but not limited to, stack popping).

Do feel free to enlighten me.

Maybe I'm getting old but VM'd language shouldn't be used for critical software. Critical as in real-time or literally life-or-death situations.

Also how should a a mathematical proof that code that uses exceptions for jumping out of iteration doesn't confuse anybody look like? It's just confusing because it's never done like that. It confuses programmers. At least one. QED?

You CAN devise your own coding style, but when using the conventions reader can safely assume couple of things. Reading code that doesn't follow these conventions is more difficult (for everybody except you).

I generally agree but I'd replace "unless they can show mathematical proof" with "unless they can show a code profile".

Happy days!

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.

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.

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

> 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 sufficient since update may also have modified 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.

The main problem with the idea of abusing exceptions as a control flow structure is the fact that they were designed to subvert and obscure the flow of control of any program that uses them. If people start to mindlessly pull clever stunts such as relying on exceptions to implement their algorithms then their code becomes unreadable, unmaintainable and unauditable. Not only their code, but any code which happens to include it. Its only purpose is to create an unmanageable pile of spaghetti code which is needlessly hard to trace. And what good comes out of it?

Interesting, I first looked at the second code segment and really didn't like it. However, I think thats just the whole Java checked exception thing (which I think everyone now regards as a mistake) - if you removed the throws and everything after it on that line it actually looks quite sensible and much better than simply returning null to mean "it didn't work for some reason I'm not going to tell you about".

The Option/Maybe monad seems the way to do it. The null object pattern could also apply here, but you have to be pretty disciplined across your project to make it really work. Seems like the kind of thing you need language support for.

Actually: while the second code block is more readable, if I encountered it in the wild I would assume that it's full of bugs. It just doesn't seem very idiomatic. I'd much rather take advantage of the 'goto' nature of the return statement:

    public Session startByInterviewId(Long interviewId, String email, String name) {
        Interview interview = interviewService.getPublicById(interviewId);
        if(interview == null) { return null; }

        Account user = userService.createUser(name, email, interview.getLocale());
        if(user == null) { return null; }

        return startByInterview(interview, user);
    }

There we go. 5 lines, one level of indentation for the main path, and semantics which are obvious to anybody who reads it.

But your point about the exceptions adding more information is well taken.

Ouch. Java's checked exception straightjacket would mean that every code that calls startByInterviewId() would either have to handle exceptions or declare "throws Interview.NotActive, Interview.NotPublic, Interview.DoesNotExist, Account.EmailExists". The longer up in the callchain, the longer the throws-list becomes until the programmer either gives up and writes "throws Exception" or is forced to handle the exceptions in a half-assed way. Likely by writing an empty catch-clause and hoping that code piece is never reached. It's especially unnerving for the user of the method if they are sure the input data is valid. For example, if interviewId comes directly from the database, then Interview.DoesNotExist can't happen so having to catch it shouldn't be needed.

Fixed your original code for you:

    public Session startByInterviewId(Long interviewId, String email, String name) {
        Interview interview = interviewService.getPublicById(interviewId);
        if (interview == null) {
            return null;
        }
     
        Account user = userService.createUser(name, email, interview.getLocale());
        if (user == null) {
            return null;
        }
     
        return startByInterview(interview, user);
    }

Besides that, you have not magically reduced LOCs, you have moved them elsewhere so these code blocks are not equivalent.

Oh, wow. On an iPad mini, the exception code is over two orders of magnitude slower in MobileSafari 6.