Exceptions for control flow considered perfectly acceptable (drmaciver.com)

    > Argument by meaningless blither. What distinguishes
    > “exceptional conditions” from “control flow”? I have
    > reached the end of a million element list. This
    > happens one time in a million! That sounds pretty
    > exceptional to me!

Keep doing your own thing.

This means that going against the grain will cost you time (and not you necessarily, but your company / colleagues, etc), and that time better come with some great benefits for it to be worthwhile.

So really, the argument can be looked at from many angles, depending on what value system you are using / what you would like to optimise for. I like to optimise for least surprises / development time.

No it’s not. Be sure to clean up anything that could need cleaning up in a finally block.

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

Writing exception safe code is very hard. Do not take my world for it. Read Alessandro Warth's paper (with Alan Kay as a co-author) [1]. Do not skip section 3...

Let me quote section 3.1:

In languages that support exception-handling mechanisms (e.g., the try/catch statement), a piece of code is said to be exception-safe if it guarantees not to leave the program in an inconsistent state when an exception is thrown. Writing exception-safe code is a tall order, as we illustrate with the following example:

  try {
  for (var idx = 0; idx < xs.length; idx++)
      xs[idx].update();
  } catch (e) {
      // ...
  }

Now, I have seen a lot of code, and very very very few times I've seen someone restoring the state of a collection after an exception blows.

[1] http://www.vpri.org/pdf/tr2011001_final_worlds.pdf

Basically, you have nested validation code, and the second you hit something which invalidates your data you throw an InvalidDataException(X), catch it at the top of the validation, and then report back to the user that their input is broken because of X.

The alternative was that every method would need to pass back whether it had found a validation error, and every place that called one would need to check that returned value. Huge numbers of lines of code, for no real gain.

(Obviously, this doesn't work if you want to return _all_ the things that are wrong with the data.)

http://jsperf.com/try-catch-error-perf/3

This drives me mad in Visual Studio, if you specify a set of exceptions to break on, then later decide you need to catch all exceptions, there's no easy way to go back to the first set.

I'm surprised this question and partial answer on Stack Overflow haven't got more votes:

http://stackoverflow.com/questions/5452480/how-to-save-and-m...

http://www.javaspecialists.eu/archive/Issue187.html and http://onjava.com/pub/a/onjava/2003/11/19/exceptions.html?pa... are two well written sources of many that Google turned up on the subject.

The main thing I would add to the original article is that the author is being a little kind to the critics on some of those points. For example, not only do exceptions not inherently need to be slow, they can actually be faster than the “classical” equivalent via return codes and the like. This is essentially because any jump-table-based exception mechanism means the non-exceptional control path can omit all the test logic that would serve only to exit the current block early. That could both reduce the size of the non-exceptional code and reduce the number of potential branches, each of which can be helpful for optimization. Although it’s rather less significant in performance terms because it only tends to happen once, when an exception does occur you also don’t have to run through all the individual levels of unwinding the stack with a jump table approach, as you can jump straight to levels that actually need to do something on their way to handling the exception and skip over anything that was just going to return immediately anyway.

As another minor data point, I haven’t found exceptions in C++ to be slow. Most/all of the major compilers seemed to have moved to a table-driven approach last time I used a broad set of them. The nasty overhead in C++ is more likely to be in the size of the generated executables; I’ve seen a compilation with exceptions disabled shave nearly 1/3 off the executable size.

Of course exceptions have somewhat different meanings and can have very different implementation overheads in different languages, so I’m not arguing that all advice to use them sparingly is bad. As always, it’s important to separate the dogma from the rational arguments.

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

    public Session startByInterviewId(Long interviewId, String email, String name)
            throws Interview.NotActive, Interview.NotPublic, Interview.DoesNotExist, Account.EmailExists {
        Interview interview = interviewService.getPublicById(interviewId);
        Account user = userService.createUser(name, email, interview.getLocale());
        return startByInterview(interview, user);
    }

Instead of just getting nulls to indicate failure I now even know exactly what caused my error.

I would never even think of writing code like this in JavaScript or Clojure though and I'd guess is that in Scala/Haskell a custom Option would be much better.

Exceptions are not suitable for control flow. Yes they work and can sometimes give nice features, but typically they are just showing that you have poorly designed code and should be doing something differently.

'/s/Exceptions/GOTO/g' and you have essentially the same argument

Because programming is just as much about communicating intent as it is about writing efficient code! Following guidelines and maxims is extremely useful because if both the writer and the reader understands the protocl, then communication is smoother.

The "Exceptions are for exceptional circumstances" protocol means that the reader of the code doesn't have to wonder "Is this a control flow situation? Is this exception supposed to be handled? Where does the code resume?"

Following the Samurai Principle (http://c2.com/cgi/wiki?SamuraiPrinciple) similarily eases the cognitive load of the person reading the code. It allows you to treat each callable piece of code as an isolated unit whose value is equal to what it returns. For non-critical code, you can completely forget about exception handling because you dont need to bother. However, if an exception is thrown you can be equally assured that something unexpected happened. It was to hard for the "samurai function" to handle. Simple and extremely convenient.

One example of not following the Samurai Principle or "exceptions for exceptional situations" happened at my last job. We were an mobile payment processor and trying to issue a charge to a customer when their balance was to low would result in a BalanceToLowException. Except that wasn't anything out of the ordinary, customers would often not have enough funds! The situation would be handled by retrying the transaction some other day. The API for charging customers would better have been designed returning a two tuple (chargeStatus,errorMsg) so that the following code could continue in the same location whether the charge succeeded or not. Throwing exceptions for ordinary events lead to spaghetti code.

You can see similar misdesigns in some database ORM:s in which some queries throw silly NoRecordsFoundException which user code is forced to handle. Or Python's classic

    try: return int(somestr) 
    except ValueError: return None 
    

However they are only few good reasons to use goto, and exceptions for control flow should be treated the same.

Therefore the point we should make against exceptions for control flow is not exceptions are for exceptional circunstances but; as a rule of thumb exceptions are for errors. And indeed they help a lot in not obscuring normal program logic, we allready have other tools for control flow.

Nobody likes goto (and my bad english)

bye

There's no compelling reason to introduce odd, non-idiomatic code patterns when they don't confer a significant benefit. Some people here argue that the "intent" of exceptions in a language design is not relevant compared to what can be done with them. In general, I disagree with this. Language designers' intent informs the expectations of readers of code, and your readers' expectations are important. Code is a form of writing for communications, both with the computer and with maintainers; it's not artistic writing, where you might deliberately violate expectations or norms in order to delight or surprise your audience.

That said, using exceptions as a method of transferring control to a non-local, dynamically-bound location is a powerful technique for which few languages offer an explicit alternative. It's also difficult for readers to analyze, so it should be used sparingly. For instance, I can think of reasons that one might use this technique within a container or algorithm library, but I can't think of a good reason for a container library to force this control flow idiom on callers by throwing exceptions to signal common situations.

(As usual, Common Lisp is unusual here. It has a throw/catch feature which is explicitly a flow control mechanism, and not just an error-handling mechanism. The standard documentation is interesting in that the Notes section suggests exactly when one would want to use this mechanism: http://www.lispworks.com/documentation/HyperSpec/Body/s_thro...)

ex. Lets assume that a problem can be attacked as algorithm1 (A1), and algorithm2 (A2). A1 is fast but cannot handle some corner cases while A2 is slow and can handle all cases. we also assume that there is no easy way to tell whether A1 is good or not without invoking A1.

So the function can be implemented as:

void A()

{

  try {
    A1();
  }
  catch (e) {
    A2();
  }

void A1()

{

  .....
  if(corner case) raise();
  .....

Is there a simple way to avoid using eceptions here?

In Objective C, exceptions are "he's dead Jim" territory.

Some of the differences of use are caused by the implementation of exceptions in those environments and the expectations programmers of libraries in those environments to what happens when exceptions occur.

To properly understand condition handling, it is critical to understand that it is primarily about protocol, rather than mere computational ability. The establishment of protocols is a sort of before-the-fact hedge against the "prisoner's dilemma"; that is, it creates an obvious way for two people who are not directly communicating to structure independently developed code so that it works in a manner that remains coherent when such code is later combined.