Back in the late 90's I worked quite a bit with a code base that used exceptions as flow control. It implemented a finite state machine to drive telephony applications. Lately I am reminded of those days because I've been doing MVC web apps.

They both have Controllers that decide where to go next and supply the data to the destination logic. User actions from the domain of an old-school telephone, like DTMF tones, became parameters to action methods, but instead of returning something like a ViewResult, they threw a StateTransitionException.

I think the main difference was that action methods were void functions. I don't remember all the things I did with this fact but I've been hesitant to even go down the road of remembering much because since that job, like 15 years ago, I never saw this in production code at any other job. I assumed this was a sign that it was a so-called anti-pattern.

Is this the case, and if so, why?

  • 4
    Related question: programmers.stackexchange.com/questions/107723
    – Eric King
    Commented Mar 4, 2013 at 22:33
  • 42
    No. In Python, using exceptions as control flow is considered "pythonic".
    – user16764
    Commented Mar 5, 2013 at 1:37
  • 6
    If I were to do such a thing I Java, I certainly would not throw an exception for it. I would derive from some non-Exception, non-Error, Throwable hierarchy. Commented Aug 15, 2014 at 14:58
  • 4
    To add to the existing answers, here is a short guideline that has served me well: - Never use exceptions for "the happy path". The happy path can be both (for web) the entire request, or simply one object / method. All the other sane rules still apply, of course :)
    – Houen
    Commented Mar 18, 2016 at 6:40
  • 19
    Aren't exceptions always controlling the flow of an application?
    – user109707
    Commented Jun 30, 2017 at 12:46

11 Answers 11


There's a detailed discussion of this on Ward's Wiki. Generally, the use of exceptions for control flow is an anti-pattern, with many notable situation - and language-specific (see for example Python) cough exceptions cough.

As a quick summary for why, generally, it's an anti-pattern:

  • Exceptions are, in essence, sophisticated GOTO statements
  • Programming with exceptions, therefore, leads to more difficult to read, and understand code
  • Most languages have existing control structures designed to solve your problems without the use of exceptions
  • Arguments for efficiency tend to be moot for modern compilers, which tend to optimize with the assumption that exceptions are not used for control flow.

Read the discussion at Ward's wiki for much more in-depth information.

See also a duplicate of this question, here

  • 32
    Your answer makes it sound as though exceptions are bad for all circumstances, while the quesion is focused on exceptions as flow control. Commented Mar 4, 2013 at 22:46
  • 19
    @MasonWheeler The difference is that for/while loops contain their flow control changes clearly and make the code easy to read. If you see a for statement in your code, you don't have to try to figure out which file contains the end of the loop. Goto's aren't bad because some god said they were, they are bad simply because they are harder to follow than the looping constructs. Exceptions are similar, not impossible but hard enough that they can confuse things.
    – Bill K
    Commented Mar 5, 2013 at 0:02
  • 28
    @BillK, then argue that, and don't make over simplistic statements about how exceptions are gotos. Commented Mar 5, 2013 at 0:14
  • 9
    Okay but seriously, what is up with server-side and app devs burying errors with empty catch statements in the JavaScript? It's a nasty phenomon that has cost me a lot of time and I don't know how to ask without ranting. Errors are your friend. Commented Mar 5, 2013 at 4:43
  • 25
    @mattnz: if and foreach are also sophisticated GOTOs. Frankly, I think the comparison with goto isn't helpful; it's almost like a derogatory term. GOTO usage isn't intrinsically evil - it has real problems, and exceptions might share those, but they might not. It would be more helpful to hear those problems. Commented Jan 11, 2015 at 12:12

The use case that exceptions were designed for is "I just encountered a situation that I cannot deal with properly at this point, because I don't have enough context to handle it, but the routine that called me (or something further up the call stack) ought to know how to handle it."

The secondary use case is "I just encountered a serious error, and right now getting out of this control flow to prevent data corruption or other damage is more important than trying to continue onward."

If you're not using exceptions for one of these two reasons, there's probably a better way to do it.

  • 30
    This doesn't answer the question though. What they were designed for is irrelevant; the only thing that is relevant is why using them for control flow is bad which is a topic you didn't touch. As an example, C++ templates were designed for one thing but are perfectly fine to be used for metaprogramming, an use the designers never anticipated of. Commented Mar 5, 2013 at 1:26
  • 6
    @Krelp: The designers never anticipated a lot of things, such as ending up with a Turing-complete template system by accident! C++ templates are hardly a good example to use here. Commented Mar 5, 2013 at 2:33
  • 19
    @Krelp - C++ templates are NOT 'perfectly fine' for metaprogramming. They are a nightmare until you get them right, and then they tend toward write-only code if you aren't a template-genius. You might want to pick a better example. Commented Mar 5, 2013 at 2:39
  • 4
    @AndreasBonini What they are designed/intended for matters because that often results in compiler/framework/runtime implementation decisions aligned with the design. For example, throwing an exception can be a lot more “expensive” than a simple return because it collects information meant to help someone debugging the code such as stack traces, etc.
    – binki
    Commented Mar 1, 2018 at 15:25
  • 1
    @binki you mean it optionally collects this information, not all exceptions do (and when they don't, at least in Java, they perform as fast as direct returns).
    – john16384
    Commented Feb 22, 2021 at 21:45

Exceptions are as powerful as Continuations and GOTO. They are a universal control flow construct.

In some languages, they are the only universal control flow construct. JavaScript, for example, has neither Continuations nor GOTO, it doesn't even have Proper Tail Calls. So, if you want to implement sophisticated control flow in JavaScript, you have to use Exceptions.

The Microsoft Volta project was a (now discontinued) research project to compile arbitrary .NET code to JavaScript. .NET has Exceptions whose semantics don't exactly map to JavaScript's, but more importantly, it has Threads, and you have to map those somehow to JavaScript. Volta did this by implementing Volta Continuations using JavaScript Exceptions and then implement all .NET control flow constructs in terms of Volta Continuations. They had to use Exceptions as control flow, because there is no other control flow construct powerful enough.

You mentioned State Machines. SMs are trivial to implement with Proper Tail Calls: every state is a subroutine, every state transition is a subroutine call. SMs can also easily be implemented with GOTO or Coroutines or Continuations. However, Java doesn't have any of those four, but it does have Exceptions. So, it is perfectly acceptable to use those as control flow. (Well, actually, the correct choice would probably be to use a language with the proper control flow construct, but sometimes you may be stuck with Java.)

  • 26
    @ErikReppen: I realize that you're just being sarcastic, but . . . I really don't think the fact that we "have dominated client-side web development with JavaScript" has anything to do with the language's features. It has a monopoly in that market, so has been able to get away with a lot of problems that cannot be written off with sarcasm.
    – ruakh
    Commented Mar 5, 2013 at 6:51
  • 1
    Tail recursion would've been a nice bonus (they're deprecating function features to have it in the future) but yes, I would say it won out against VB, Flash, Applets, etc... for feature-related reasons. If it didn't reduce complexity and normalize as handily as it does it would have had real competition at some point. I'm currently running Node.js to handle the rewriting of 21 config files for a hideous C# + Java stack and I know I'm not the only one out there doing that. It's very good at what it's good at. Commented Mar 5, 2013 at 14:33
  • 2
    @Shayne: those are not universal. It is not possible to implement all control flow in terms of one of them. You can't implement exceptions or threads or GOTO using just if. In fact, a language with if and for isn't even Turing-complete! (A language with only while and nothing else OTOH, is.) You say, exceptions aren't needed, then show how you would implement threads in ECMAScript using just subroutine calls, if and while. And note that Volta was written targetting ES3, so no WebWorkers, no Promises, no Proper Tailcalls. Commented Nov 14, 2014 at 3:24
  • 2
    Well yes you might be right about if. "For" in its C style form however can be used as an awkwardly stated while, and a while can then be used coupled with an if to implement a finite state machine that can then emulate all other flow control forms. Again, stinky way to code, but yeah. And again, goto considered harmful. (And I'd argue, so too with using exceptions in non exceptional circumstances). Keep in mind there are perfectly valid, and very powerful languages that provide neither goto nor exceptions and work just fine.
    – Shayne
    Commented Nov 19, 2014 at 4:38
  • 2
    I'm curios about how exceptions can be used to implement continuations ..
    – hasen
    Commented Jan 11, 2015 at 8:50

As others have mentioned numerously, (e.g. in this Stack Overflow question), the principle of least astonishment will forbid that you use exceptions excessively for control flow only purposes. On the other hand, no rule is 100% correct, and there are always those cases where an exception is "just the right tool" - much like goto itself, by the way, which ships in the form of break and continue in languages like Java, which are often the perfect way to jump out of heavily nested loops, which aren't always avoidable.

The following blog post explains a rather complex but also rather interesting use-case for a non-local ControlFlowException:

It explains how inside of jOOQ (a SQL abstraction library for Java) (disclaimer: I work for the vendor), such exceptions are occasionally used to abort the SQL rendering process early when some "rare" condition is met.

Examples of such conditions are:

  • Too many bind values are encountered. Some databases do not support arbitrary numbers of bind values in their SQL statements (SQLite: 999, Ingres 10.1.0: 1024, Sybase ASE 15.5: 2000, SQL Server 2008: 2100). In those cases, jOOQ aborts the SQL rendering phase and re-renders the SQL statement with inlined bind values. Example:

    // Pseudo-code attaching a "handler" that will
    // abort query rendering once the maximum number
    // of bind values was exceeded:
    String sql;
    try {
      // In most cases, this will succeed:
      sql = query.render();
    catch (ReRenderWithInlinedVariables e) {
      sql = query.renderWithInlinedBindValues();

    If we explicitly extracted the bind values from the query AST to count them every time, we'd waste valuable CPU cycles for those 99.9% of the queries that don't suffer from this problem.

  • Some logic is available only indirectly via an API that we want to execute only "partially". The UpdatableRecord.store() method generates an INSERT or UPDATE statement, depending on the Record's internal flags. From the "outside", we don't know what kind of logic is contained in store() (e.g. optimistic locking, event listener handling, etc.) so we don't want to repeat that logic when we store several records in a batch statement, where we'd like to have store() only generate the SQL statement, not actually execute it. Example:

    // Pseudo-code attaching a "handler" that will
    // prevent query execution and throw exceptions
    // instead:
    // Collect the SQL for every store operation
    for (int i = 0; i < records.length; i++) {
      try {
      // The attached handler will result in this
      // exception being thrown rather than actually
      // storing records to the database
      catch (QueryCollectorException e) {
        // The exception is thrown after the rendered
        // SQL statement is available

    If we had externalised the store() logic into "re-usable" API that can be customised to optionally not execute the SQL, we'd be looking into creating a rather hard to maintain, hardly re-usable API.


In essence, our usage of these non-local gotos is just along the lines of what Mason Wheeler said in his answer:

"I just encountered a situation that I cannot deal with properly at this point, because I don't have enough context to handle it, but the routine that called me (or something further up the call stack) ought to know how to handle it."

Both usages of ControlFlowExceptions were rather easy to implement compared to their alternatives, allowing us to reuse a wide range of logic without refactoring it out of the relevant internals.

But the feeling of this being a bit of a surprise to future maintainers remains. The code feels rather delicate and while it was the right choice in this case, we'd always prefer not to use exceptions for local control flow, where it is easy to avoid using ordinary branching through if - else.


Using exceptions for control flow is generally considered an anti-pattern, but there are exceptions (no pun intended).

It has been said a thousand times, that exceptions are meant for exceptional conditions. A broken database connection is an exceptional condition. A user entering letters in an input field that should only allow numbers is not.

A bug in your software that causes a function to be called with illegal arguments, e.g. null where not allows, is an exceptional condition.

By using exceptions for something that is not exceptional, you are using inappropriate abstractions for the problem you are trying to solve.

But there can also be a performance penalty. Some languages have more or less efficient exception handling implementation, so if your language of choice does not have efficient exception handling, it can be very costly, performance-wise*.

But other languages, for example Ruby, have an exception-like syntax for control flow. Exceptional situations are handled by the raise/rescue operators. But you can use throw/catch for exception-like control flow constructs**.

So, although exceptions are generally not used for control flow, your language of choice may have other idioms.

* En example of a performance costly use of exceptions: I was once set to optimize a poorly performing ASP.NET Web Form application. It turned out, that the rendering of a large table was calling int.Parse() on approx. a thousand empty strings on an average page, resulting in approx. a thousand exceptions being handled. By replacing the code with int.TryParse() I shaved off one second! For every single page request!

** This can be very confusing for a programmer coming to Ruby from other languages, as both throw and catch are keywords associated with exceptions in many other languages.


Programming is about work

I think the easiest way to answer this is to understand the progress OOP has made over the years. Everything done in OOP (and most programming paradigms, for that matter) is modeled around needing work done.

Every time a method is called, the caller is saying "I don't know how to do this work, but you do know how, so you do it for me."

This presented a difficulty: what happens when the called method generally knows how to do the work, but not always? We needed a way to communicate "I wanted to help you, I really did, but I just can't do that."

An early methodology to communicate this was to simply return a "garbage" value. Maybe you expect an positive integer, so the called method returns a negative number. Another way to accomplish this was to set an error value somewhere. Unfortunately, both ways resulted in boilerplate let-me-check-over-here-to-make-sure-everything's-kosher code. As things grow more complicated, this system falls apart (or must be very carefully managed).

An Exceptional Analogy

Let's say you have a carpenter, a plumber, and an electrician. You want to plumber to fix your sink, so he takes a look at it. It's not very useful if he tells only you, "Sorry, I can't fix it. It's broken." Hell, it's even worse if he were to take a look, leave, and mail you a letter saying he couldn't fix it. Now you have to check your mail before you even know he didn't do what you wanted.

What you would prefer is to have him tell you, "Look, I couldn't fix it because it seems like your pump isn't working."

With this information, you can conclude you want the electrician to take a look at the problem. Perhaps the electrician will find something related to carpenter, and you'll need to have the carpenter fix it.

Heck, you might not even know you need an electrician, you might not know who you need. You're just middle-management in a home repair business, and your focus is plumbing. So you tell you're boss about the problem, and then he tells the electrician to fix it.

This is what exceptions are modeling: complex failure modes in a decoupled fashion. The plumber doesn't need to know about electrician- he doesn't even need to know that someone up the chain can fix the problem. He just reports on the problem he encountered.

So... an anti-pattern?

Ok, so understanding the point of exceptions is the first step. The next is to understand what an anti-pattern is.

To qualify as an anti-pattern, it needs to

  • solve the problem
  • have definitively negative consequences

The first point is easily met- the system worked, right?

The second point is stickier. The primary reason for using exceptions as normal control flow is bad is because that's not their purpose. Any given piece of functionality in a program should have a relatively clear purpose, and co-opting that purpose leads to unnecessary confusion.

But that's not definitive harm. It's a poor way to do things, and weird, but an anti-pattern? No. Just... odd.

  • There's one bad consequence, at least in languages providing a full stack trace. As the code is heavily optimized with a lot of inlining, the real stack trace and the one a developer wants to see differ a lot and therefore the stack trace generation is costly. Overusing exceptions is very bad for performance in such languages (Java, C#).
    – maaartinus
    Commented Jan 6, 2017 at 4:03
  • "It's a poor way to do things" - Shouldn't that be enough to classify it as an anti-pattern? Commented Apr 5, 2018 at 6:30
  • 1
    @Maybe_Factor Per the definition of an ant-pattern, no. Commented Apr 6, 2018 at 17:31
  • @MirroredFate i like how you separated the problem it solves from the negatives. i think this is a pretty good. except for the last section about anti-pattern. you could mention lower performance as a negative consequence. you could also give a concrete example of exception as control flow, so that we are all on the same page. you could even give an example of exceptions fixing the the arrow anti-pattern, before the last section
    – symbiont
    Commented Nov 17, 2022 at 8:09
  • There are two exceptions, low level and high-level. A low level exception is one thrown by a file or keyboard io function further down the stack, for instance. A high level one catches a lower level one and rethrows it as is, or rethrows it with a more specific or detailed message which can be presented to the user. High level exceptions can be abused, but they are the best way of meaningfully reporting errors.
    – user148298
    Commented Aug 13, 2023 at 3:44

It's completely possible to handle error conditions without the use of exceptions. Some languages, most notably C, don't even have exceptions, and people still manage to create quite complex applications with it. The reason exceptions are useful is they allow you to succinctly specify two essentially independent control flows in the same code: one if an error occurs and one if it doesn't. Without them, you end up with code all over the place that looks like this:

status = getValue(&inout);
if (status < 0)
    return status;


Or equivalent in your language, like returning a tuple with one value as an error status, etc. Often people who point out how "expensive" exception handling is, neglect all the extra if statements like above that you are required to add if you don't use exceptions.

While this pattern happens to occur most often when handling errors or other "exceptional conditions," in my opinion if you start seeing boilerplate code like this in other circumstances, you have a pretty good argument for using exceptions. Depending on the situation and implementation, I can see exceptions being used validly in a state machine, because you have two orthogonal control flows: one that's changing the state and one for the events that occur within the states.

However, those situations are rare, and if you're going to make an exception (pun intended) to the rule, you had better be prepared to show its superiority to other solutions. A deviation without such justification is rightly called an anti-pattern.

  • 3
    As long as those if statements only fail on 'exceptional' circumstances the branch prediction logic of modern CPUs make their cost negligible. This is one place where macros can actually help, as long as you're careful and don't try to do too much in them.
    – James
    Commented Mar 5, 2013 at 0:25
  • This doesn't answer the question at all. Many things are "completely possible" without X.
    – john16384
    Commented Feb 22, 2021 at 21:34

In Python, exceptions are used for generator and iteration termination. Python has very efficient try/except blocks, but actually raising an exception has some overhead.

Due to lack of multi-level breaks or an goto statement in Python, I have at times used exceptions:

class GOTO(Exception):

  # Do lots of stuff
  # in here with multiple exit points
  # each exit point does a "raise GOTO()"
except GOTO:
except Exception as e:
  #display error
  • 7
    If you have to terminate calculation somewhere in a deeply nested statement and go to some common continuation code, this particular path of execution can very probably be factored out as a function, with return in place of goto.
    – 9000
    Commented Mar 5, 2013 at 0:40
  • 3
    @9000 I was about to comment exactly the same thing ... Keep try: blocks to 1 or 2 lines please, never try: # Do lots of stuff.
    – wim
    Commented Mar 5, 2013 at 3:57
  • 3
    @9000, in some cases, sure. But then you lose access to local variables, and you move your code yet-another-place, when the process is a coherent, linear process.
    – gahooa
    Commented Mar 14, 2013 at 5:45
  • 4
    @gahooa: I used to think like you. It was a sign of poor structure of my code. When I put more thought in it, I noticed that local contexts can be untangled and the whole mess made into short functions with few parameters, few lines of code, and very precise meaning. I never looked back.
    – 9000
    Commented Mar 14, 2013 at 5:52

Let's sketch such an Exception usage:

The algorithm searches recursively till something is found. So coming back from recursion one has to check the result for being found, and return then, otherwise continue. And that repeatedly coming back from some recursion depth.

Besides needing an extra boolean found (to be packed in a class, where otherwise maybe only an int would have been returned), and for the recursion depth the same postlude happens.

Such an unwinding of a call stack is just what an exception is for. So it seems to me a non-goto-like, more immediate and appropriate means of coding. Not needed, rare usage, maybe bad style, but to-the-point. Comparable with the Prolog cut operation.

  • Hmm, is the downvoting for the indeed contrary position, or for insufficient or short argumentation? I am really curious.
    – Joop Eggen
    Commented Oct 20, 2014 at 21:09
  • I'm facing exactly this predicament, I was hoping you could see what you think of my following question? Recursively using exceptions to accumulate the reason (message) for a top level exception codereview.stackexchange.com/questions/107862/…
    – Jodes
    Commented Oct 19, 2015 at 14:36
  • @Jodes I have just read your interesting technique, but I am quite occupied for now. Hope someone else will shed her/his light on the issue.
    – Joop Eggen
    Commented Oct 19, 2015 at 15:01

The "pro-antipattern" argument is not very strong and is having it's own internal debate:

The same reference used to support the antipattern case can also be found to support the benefits of exceptions:


Further, I believe the case made that it is an antipattern is pretty weak:

From the oft-referenced wiki: enter image description here

The best example is a for loop with no constraint? Who would do this?

On that very same page he admits to using exceptions for flow control:

enter image description here

"Flow control" by itself is overly generalized The term "flow control" has limited use as it describes the meat and potatoes of programming. There is no black and white here, only shades of gray.

Sure, it makes little sense to catch an exception raised by Parse when a TryParse exists. But that does not mean that the tester-doer pattern needs to apply to every method. Do we really need a TrySave()? Or can we say that there is some level of granularity that represents a tipping point for when we should be able to simply code for the successful case (should Save() simply continue if it failed??)?

In the absence of exceptions, what choice do you have? I guess if this is an antipattern but the same reference is indicating that return codes should be avoided (I consider true/false return codes), what are we supposed to do?

  1. Exceptions introduce a completely unnecessary, heavy performance hit that you don't ever need to take if you just use a return code (like most APIs do)
  2. Programmers tend to consider exceptions as "something that just doesn't/or very rarely happens", so they often just dump all "bad" program state to an exception block with no recovery code other than a printStackTrace/send this in to our developers.

Not the answer you're looking for? Browse other questions tagged or ask your own question.