When sending a request to another module and expecting a result, it seems to me there are two ways of dealing with the 'non-happy paths'.

  • Throw an exception
  • Return a result object that wraps different results (such as value and error)

I would say the first one seems better in general. It keeps the code clean and readable. If you expect the result to be correct, just throw an exception to handle happy path divergence.

But what when you have no clue what the result will be?

For example calling a module that validates a lottery ticket. The happy path would be that you won, but it probably won't be. (As pointed out by @Ben Cottrell in the comments, "not winning" is also the happy path, maybe not for the end user, though)

Would it be better to consider that the happy path is getting a result from the LotteryTicketValidator and just handle exceptions for when the ticket could not be processed?

Another one could be user authentication when logging in. Can we assume that the user entered the correct credentials and throw an exception when the credentials are invalid, or should we expect to get some sort of LoginResult object?

  • 60
    "the happy path would be that you won" -- No, that's not what the term happy path means. A losing ticket is very much 'happy path' because it's a scenario you should expect to handle in the business logic. Happy Path means that nothing unexpected happens - for example, locked files on disk, database exceptions, network interruptions, internal errors in 3rd-party libraries or API, expired certificate, etc. User auth is the same - a user's invalid username or password is also Happy path. In fact, any kind of user input validation is 'happy path'. – Ben Cottrell Feb 12 at 8:38
  • 17
    @dumazy 401 is an HTTP response status code. Not an application exception. They are two very distinct concepts. Users entering incorrect passwords is not an exception scenario. – Ant P Feb 12 at 8:47
  • 9
    This question is somewhat language specific though, iirc Python encourages use of exceptions in normal control flow. – Ant P Feb 12 at 8:48
  • 6
  • 23
    Ironically, does this mean if you build a lottery system and you win the lottery, you should throw a LotteryWonException, because you never expect to win? – Matthew Feb 12 at 18:06

11 Answers 11


You have to distinguish between return values and errors.

A return value is one of many possible outcomes of a computation. An error is an unexpected situation which needs to be reported to the caller.

A module may indicate that an error occurred with a special return value or it throws an exception because an error was not expected. That errors occur should be an exception, that's why we call them exceptions.

If a module validates lottery tickets, the outcome may be:

  • you have won
  • you have not won
  • an error occurred (e.g. the ticket is invalid)

In case of an error, the return value is neither "won" nor "not won", since no meaningful statement can be made when e.g. the lottery ticket is not valid.


One might argue that invalid tickets are a common case and not an error. Then the outcome of the ticket validation will be:

  • you have won
  • you have not won
  • the ticket is invalid
  • an error occurred (e.g. no connection to the lottery server)

It all depends on what cases you are planning to support and what are unexpected situations where you do not implement logic other than to report an error.

  • 12
    Surely 'Invalid ticket' would be a normal part of validation and therefore something which should be expected rather than an error per-se. For example, a user could quite legitimately present the system with the wrong barcode, type the wrong ticket number, enter the number for an expired ticket, enter a number for a ticket which has already paid out winnings, etc. Unexpected errors would be things like network failure or a back-end service becoming unavailable – Ben Cottrell Feb 12 at 10:15
  • @BenCottrell Well, my example for an error case may not be the best, see the "Addendum" section. – helb Feb 12 at 10:18
  • 1
    "Server performing the ticket validation is down" would be an exception. Well, we hope it's an exception :-( – gnasher729 Feb 12 at 13:24
  • 23
    Ahh but then one could argue that "because the shop is in a remote location with flaky cell/net coverage, not being able to contact the server is every bit as expected an error as the user typing in an invalid ticket number etc.." and so it goes on, down into the navel fluff of every possible thing. I would thus say it's not so much about unexpected conditions, but about only covering for a reasonable number of conditions before one reaches the point of throwing the towel in.. – Caius Jard Feb 12 at 17:27
  • 6
    Oh, it wasn't a criticism, it was more that your last sentence said "what are unexpected situations" whereas I'm advocating that it may not be so much about expected/unexpected, it's about reasonable-to-code-for/unreasonable-to-code-for - I can fully expect the lottery server being unavailable, but the judgement call of whether to code for it (or any of the other hundred things I can "expect" to go wrong) or not is the threshold of "how much defense for situation X do we want to go to the effort of writing". – Caius Jard Feb 12 at 18:08

This is a good question that professional developers have to consider carefully. The guideline to follow is that exceptions are called exceptions because they are exceptional. If a condition can be reasonably expected then it should not be signaled with an exception.

Let me give you a germane example from real code. I wrote the code which does overload resolution in the C# compiler, so the question I faced was: is it exceptional for code to contain overload resolution errors, or is it reasonably expected?

The C# compiler's semantic analyzer has two primary use cases. The first is when it is "batch compiling" a codebase for, say, a daily build. The code is checked in, it is well-formed, and we're going to build it in order to run test cases. In this environment we fully expect overload resolution to succeed on all method calls. The second is you are typing code in Visual Studio or VSCode or another IDE, and you want to get IntelliSense and error reports as you're typing. Code in an editor is almost by definition wrong; you wouldn't be editing it if it were perfect! We fully expect the code to be lexically, syntactically and semantically wrong; it is by no means exceptional for overload resolution to fail. (Moreover, for IntelliSense purposes we might want a "best guess" of what you meant even if the program is wrong, so that the IDE can help you correct it!)

I therefore designed the overload resolution code to always succeed; it never throws. It takes as its argument an object representing a method call and returns an object which describes an analysis of whether or not the call is legal, and if not legal, which methods were considered and why each was not chosen. The overload resolver does not produce an exception or an error. It produces an analysis. If that analysis indicates that a rule has been violated because no method could be chosen, then we have a separate class whose job it is to turn call analyses into error messages.

This design technique has numerous advantages. In particular, it allowed me to easily unit-test the analyzer. I feed it inputs that I've analyzed "by hand", and verify that the analysis produced matches what I expected.

Can we assume that the user entered the correct credentials and throw an exception when the credentials are invalid, or should we expect to get some sort of LoginResult object?

Your question here is about what I think of as "Secure Code" with capitals. All code should be secure code, but "Secure Code" is code that directly implements aspects of a security system. It is important to not use rules of thumb/tips and tricks/etc when designing Secure Code because that code will be the direct focus of concerted attacks by evildoers who seek to harm your user. If someone manages to sneak wrong code past my overload resolution detector, big deal, they compile a wrong program. But if someone manages to sneak past the login code, you have a big problem on your hands.

The most important thing to consider when writing Secure Code is does the implementation demonstrate resistance to known patterns of attack, and that should inform the design of the system.

Let me illustrate with a favourite example. Fortunately this problem was detected and eliminated before the first version of .NET shipped, but it did briefly exist within Microsoft.

"If something unexpected goes wrong in the file system, throw an exception" is a basic design principle of .NET. And "exceptions from the file system should give information about the file affected to assist in debugging" is a basic design principle. But the result of these sensible principles was that low-trust code could produce and then catch an exception where the message was basically "Exception: you do not have permission to know the name of file C:\foo.txt".

The code was not initially designed with a security-first mindset; it was designed with a debuggability-first mindset, and that often is at cross-purposes to security. Consider that lesson carefully when designing the interface to a security system.

  • 2
    While I like your post, I think with regards to the exceptions Microsoft erred on the wrong side. MOST system do not need to be as hardened to attack that almost any exception needs to be useless to aid in error correction. The should have been a switch to neuter exceptions, but it should have been off by default. – Christian Sauer Feb 13 at 7:47
  • 2
    @ChristianSauer: If you've jumped through the hoops of intentionally running code as low-trust, you probably do want that level of hardening. – Brian Feb 13 at 19:31

I'm going to take a slightly different track (I hope) than the other answers. A method should throw an exception when it's unable to fulfill its contract, which is based on how you name the method. The other answers say "exceptions for exceptional conditions," which I think can lead to some questionable design choices in some situations.

There are times where it can be hard to say if something which happens during the execution of a method should be rare (and thus exception) or a normal result path. Thinking about "did the method perform what its intended function" helps clarify things, IMO.

For example, the implementation uses a web service. Is it normal that service call might fail or be unavailable, or is that an exception case? Does it matter if you know that the service is very reliable (almost always able to be called successfully, in which case you'd say failure is exceptional and thus should throw) or if you know that the service fails frequently (which could lead you to a result code design)? The answer is that for your API, it doesn't matter; the service is an implementation detail and users of your API shouldn't care about HOW the validate method works, only that the method was able to validate (thus a result), or not (thus throws).

So a ValidateLotteryTicket method should return a result if the ticket is a winner, if its not a winner, or if the ticket number is invalid. It should throw an exception if something prevents it from actually validating the ticket, perhaps due a network error, the host process is shutting down, or the host machine is out of memory to continue. The validate method should only return if it was able to perform the validation and come to a conclusion.

A method to Login should throw if it is unable to log the user in; again, perhaps there's a network error preventing the credential validation, maybe the account is locked, maybe the password is invalid, or even the system was unable to log a login audit record after successfully validating the credentials. The expectation when Login is called and returns is that the user is now logged in with appropriate privileges assigned. If Login cannot exit in that state, it should throw an exception.

  • 1
    Absolutely. Another way of wording this is "The method is unable to fulfil the contract established by its name". If the method's name says that it will validate the lottery ticket, it should show an exception if it is unable to fulfil that contract: if it is unable to validate the lottery ticket. Then of course you have the discussion around what "validate" actually means in your domain... – canton7 Feb 13 at 9:29
  • 1
    @canton7 Excellent way of wording it; I wish there were more emphasis on contracts. I'll edit your wording into my answer. – Andy Feb 13 at 15:30
  • 1
    @canton7 Method names are almost never sufficient documentation. Contracts should be documented in doc comments or the language's equivalent. – user560822 Feb 13 at 16:51
  • I like this, as it isn't based on how rare the exceptional case might be. It also means that a short method name like pay should have exceptions declared on it for insufficient balance or invalid account, or it should be named payIfSufficientBalanceAndAccountValid with an appropriate result type detailing the final result. – john16384 2 days ago
  • It took me a little while before I understood what you were saying about the Login method. I think your answer would benefit if you compared it with a method to validate credentials. – Wes Toleman 2 days ago

This very much depends on the environment and language you are working in. (SE Stackexchange is overrun with Java programmers, and most of the answer demonstrate as much.)

There are several common techniques:

1. Return values

Go doesn't have automatically propagating errors. All error handling is explicitly handled by returning a result and an optional error.

 f, err := os.Open(path)
 if err != nil {

In functional languages, there is often an Either/Result monad that is used for this.

2. Out parameter

C# has output parameters. For example int.TryParse. It returns the success/failure and modifies the argument to store the resulting value.

int number;
if (int.TryParse(text, out number)) {

C functions often do similar things, using pointers.

3. Errors in exceptional cases only

Conventional Java/C# wisdom is that errors are appropriate in "unusual" cases. This largely depends on the level you are working at.

A failure to establish a TCP connection might be an error. An failed remote authentication attempt (e.g. HTTP 401/403) might be an error. A failure to create a file due to a conflict might be an error.

try {
    socket = serverSocket.accept();
} catch (IOException e) {

There is usually a taxonomy of errors (e.g. in Java, "errors" are severe, program-threatening events, "unchecked exceptions" are indication of programmer error, and "checked exceptions" are unusual but expected possibilities).

4. Errors generally

In Python, errors are an acceptable and idiomatic form of flow control, just as much as if-then for for.

    a = things[key]
except KeyError:

I recommend finding the pattern for your language/ecosystem/project and sticking to that.

  • 4
    Checked exceptions are not necessarily unusual. Their defining characteristic is that they represent an error that is both external (i.e., not a bug) and potentially recoverable. In other words, they're exceptions that should be caught by the application. Errors are external and unrecoverable; they're only catchable so applications can log them before exiting. – user560822 Feb 13 at 17:06
  • @user560822, idiomatically, Java exceptions are for "not normal" situations softwareengineering.stackexchange.com/a/189225 But they can be used in many ways. – Paul Draper Feb 14 at 20:17
  • Java's checked exceptions were intended to signal expected error conditions like "file not found" that a robust program should handle. It was an attempt at adding compiler support for forcing the programmer to handle these kinds of common errors. An external error being rare was actually an argument for making what would otherwise be a checked exception into an unchecked exception. – user560822 Feb 14 at 20:32
  • Checked exceptions allows you to make something part of the method contract that must be dealt with, just like its result value and parameters are part of its contract -- the compiler will flag breaches of these contracts, whether it is not catching an exception, passing a String where an int is expected or assigning the result to a wrong variable type. – john16384 2 days ago

Ultimately it is a matter of what is idiomatic in the language you are writing in.

I read through the answers and was shocked to find no mention of rust, which is the first language which comes to mind which advocates (kind of forces) the user to returns errors/null values wrapped in result objects. As in illustrative example, one such type is:

Result<T, E> is the type used for returning and propagating errors. It is an enum with the variants, Ok(T), representing success and containing a value, and Err(E), representing error and containing an error value.

  • I'm not familiar with rust; what if the result contains an error, does it somehow force you to handle the error if there is one, or can it be ignored? – Andy Feb 13 at 15:46
  • 2
    @Andy This pattern is commonly used in functional programming languages, too You are generally free to ignore it just like you are free to do nothing in an exception handler. However, APIs tend to be written in such a way that ignoring the return value doesn't make any sense, and you'll generally be using pattern matching (which force you to explicitly propagate or handle) and/or some monadic operations (which will propagate errors nicely). – gustafc Feb 13 at 16:48
  • 2
    The nice thing with this approach, is that you can handle result values just like you handle any other value in the programming language - you're not forced to handle an error in the same call stack as it happened. This becomes very handy when you're doing map/flatMap/filter/reduce chains on collections, for example. – gustafc Feb 13 at 16:56
  • "first language that comes to mind" Haskell came to my mind before Rust was even a twinkle. And C as well, though the error paradigms for C are varied. – Paul Draper Feb 14 at 20:20

Exceptions cause you problems when you work with callbacks. It's very often that you call some code, it does things in the background, then calls the callback, and it is really helpful to your sanity if you know the callback will be called, no matter what happens (for example what errors happened). Very often the caller is long gone by the time you find a reason to throw an exception.

In that case, returning error + result is much easier to handle correctly. In Swift, an enum containing two cases for error and result is actually part of the standard library for exactly that reason.

  • 2
    Although I think many languages today do "background stuff" via async await, and exceptions which occur in the async part are thrown when the async operation is awaited. – Andy Feb 13 at 0:34
  • 1
    Scala has a similar idiom with its Either type being used to represent return values which can either be a normal result or an error. – Christian Hackl Feb 13 at 7:13
  • The callback is simply poorly written if it doesn't catch exceptional cases (and either handles them, logs them or wraps them). Even functions which donot throw documented exceptions can throw exceptions at any time if they're dealing with any kind of I/O for example. – john16384 2 days ago

The everything returns a result model is used by COM; practically every method returns a HRESULT. Because of this, you wind up with code that looks like this:

HRESULT hr = object1.CallMethod1( ... ); 
if ( IS_ERROR( hr ) )
   return ; 

hr = object1.CallMethod2(); 
if ( IS_ERROR( hr ) )
   return ; 

hr = object1.CallMethod3( ... ); 
if ( IS_ERROR( hr ) )
   return ; 

and so on ...

It a style of coding, but it makes for a lot of code to achieve, in some cases, not very much.

The Good thing about C++:

  • You can write code to do almost anything with it.

The not so Good thing about C++:

  • You have to write code to do anything with it.

Exceptions allow you to cut through this "Stepping through the Minefield" style of coding.

Your code just keep painting the floor until you unexpectedly find yourself in a corner, at which point it throws an Exception, effectively abandoning the rest of the room and jumping out of the window, in the hope that something is going to catch it.

  • Nice analogy ;-) You may want to mention that return values in COM are usually passed with [out] parameters. – helb Feb 12 at 12:17
  • @helb: I can't believe I'd actually /forgotten/ that! It /has/ been a while since I tip-toed through the Minefield ... – Phill W. Feb 12 at 16:20
  • I believe OP is talking about the modern functional programming concept of the "Result" type, which is pretty significantly different than HRESULT. Most implementations of "Result" will (usually) slightly decrease the amount of code you have compared to exceptions, if you use them functionally. – Clay07g Feb 13 at 2:31
  • Well-written C++ should produce less code than other languages because of the prevalence of value types, RAII and move semantics, which in turn drastically reduces exception handling at higher abstraction levels. In particular, you don't have to manually free handles returned from C APIs anymore if destructors do it for you automatically, whereas in certain other languages the code would be littered with finally blocks and other manual resource mangagement. Of course, COM programming itself is difficult and old-fashioned, but that has little to do with the programming language. – Christian Hackl Feb 13 at 6:45
  • @ChristianHackl: Unfortunately, C++ has no good way of handling the fact that an attempt to release a resource in response to an exception may fail in ways that an application would need to know about. – supercat Feb 14 at 19:29

The dichotomy isn't between "exceptions" and "results" objects.

In reality, it's in the distinction between unexpected or fatal VS anticipable or recoverable errors, and whether the calling program can reasonably do something to change the outcome when the error is reported (as opposed to requiring a program change).

This distinction has gotten muddied by many modern languages that set both types (unexpected/recoverable errors) up as "exceptions":

  1. Attempting to parse an integer to a string fails if there are no digits in the string data, yielding an ArgumentInvalidException.
  2. Attempting to parse an integer to a string fails if there is insufficient memory to allocate the string object, yielding an OutOfMemoryException.

In the case of 1., the error is anticipable, and the program should be able to gracefully handle the case (see also Railway-Oriented Programming; note this is about handling the errors, not using an explicit Result<T, Error> object).
In the case of 2., the error is neither anticipable, nor is it (likely) recoverable. The only reasonable avenue left is to crash the program.

For a practical look at the differences, I recommend reading this blog post about the Midori error model.

  • 1
    If code is trying to parse an integer which is going to be valid unless an input file is sufficiently corrupted as to render any attempts at parsing meaningless, there's really not much benefit to having the parser's immediate calling code try to handle a parse fail gracefully. Unfortunately, existing languages' exception mechanisms are poorly adapted to distinguish between scenarios where a function fails without adverse side effects, and those where failure could leave an object in a corrupted state. Proper Dispose handling for things like lock tokens should distinguish between... – supercat Feb 12 at 23:21
  • ...cases where code that uses a token completes normally (implying the lock should be released) and cases where it exits via an exception (implying that if the token was acquired for writing, the lock should be invalidated such that all pending and future acquisition attempts fail instantly). Unfortunately, without a provision for that, distinguishing between recoverable and unrecoverable failures will be very difficult. – supercat Feb 12 at 23:24
  • @supercat - Files being unreadable (whether due to byte twiddling or just a wrong text block) is an anticipable error. If that means your application can't process that file any further, then don't do so (or stop the program). Otherwise, if you're trying to lock the file such that other programs can't read it, that's usually poor behavior. – Clockwork-Muse Feb 12 at 23:56

In short: it depends.

Taking the lottery ticket example:
bool isWinningTicket(const LotteryTicket& ticketToCheck)

One could argue that an invalid ticket is (by default) not a winning ticket, so let's look at the "validation servers unreachable" scenario. In that case the function cannot provide what it promised - a true / false reply if the ticket is a winning ticket - so it should throw an exception to make you aware of that.

Why? Let's consider the alternatives, like
bool checkIfTicketIsWinningTicket(const LotteryTicket& ticketToCheck, bool& isWinning)
Stores the true/false (if the ticket is winning) result in the out-parameter bool& isWinning and indicates success/failure of the function itself by returning true/false, no exceptions, no hassle... except (pardon the pun) - you might, by accident, forget to check the return value, miss that the function failed, and give false positives/negatives (each of which makes different people unhappy).

If you forget to catch the exception in the first example... you'll get an run-time error and that should make you aware that something is wrong with your code (unless you went out of your way to write catch(...) { /*do nothing*/ } but then no one can help you anyway). In the second case your code will fail silently, and you will only notice when either angry lottery people or angry ticket holders knock down your door...

As for the login example: If your function void loginUser(User userToLogIn, Password passwordOfUser) - promises to log valid users (i.e. people are expected to call bool isValidUser(User u, Password p) beforehand and after loginUser()is called the user will be logged in) then an exception for invalid user/password combinations is correct. If the function works on a "see if the combination is valid and log in if it is" basis, then you shouldn't throw an exception for that (and give the function a different name).


The question is already answered, but I think that a lot more should be said on the argument. First of all there should be a separation between technical errors and business errors. Exceptions should be used to handle technical errors, not the business ones. The primary reason is that they maybe back-propagated and disrupt the whole logic flow. It makes sense to stop processing when you have an IO Error or the network is missing because all the other services, modules, subcalls may stop working for the same reason. Furthermore a technical error is something that usually is unexpected and the developer can't implement specific paths to handle all the possible technical errors.

A business error most of the times is something well known and a proper path, to handle it, can be easily designed. Obviously with try/catch a proper path could be implemented also when there is an exception, but when different people work on the same application or maintenance is done after a long time someone could easily forget to add the required try/catch and the error could end up being improperly reported.

Another point is that business and technical errors should be reported to different people. Using the try/catch flow to handle everything makes difficult to separate them. When something like "you have not won" or "the ticket is invalid" happens the application might just send a message to the user. The above mentioned "IO error" instead might require the intervention of a sysadmin.

The only exception I see to this rule are some kind of error that are not clearly defined and the developer does not know how to handle. The most common case is when there are constraints in the input data, there could be too many ways a constraint might be violated and as a matter of fact usually in Java when it happens the input data is bounced back with an IllegalArgumentException.


I'd put it the other way around and consider an exception (or Throwable in Java terms) a specially treated return object (as it is optional to throw) with one very distinctive feature.

It has a stack trace attached to it!

A stack trace used to be a very expensive ting to generate by the JVM (it has become better) but this was more than outweighed by its usefulness to the programmer reading it to debug the program. This is also why chained exceptions were added to Java 1.4.

So the question I think you should be asking yourself is:

Do I need a stack trace for this situation?

If the answer is not a resounding yes, then don't. Use a more suited data structure.

  • Java atleast allows you create exceptions without stacktraces and avoid the penalty (if that isn't a case of premature optimization in the first place) by disable writableStrackTrace. You can also create exceptions that are static (if the exception class is sufficient information to identify the problem) by making the exception immutable (writableStackTrace and enableSuppression both set to false) – john16384 2 days ago
  • @john16384 Interesting. Appears to have been added in Java 7, but I cannot find out why. Doing this will in my opinion sacrifice clarify for no good (to me) reason. – Thorbjørn Ravn Andersen 2 days ago

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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