I've been thinking about that for quite a while actually. I am not a native English speaker myself but still, I have years of programming experience and I always asked myself this. Why is it named as Exception but not Error since they are errors?

It could be PageNotFoundError instead of PageNotFoundException!

  • 43
    Not all exceptional situations are errors. Commented Aug 18, 2012 at 23:23
  • 15
    It's the difference between swerving the car and crashing the car.
    – user28988
    Commented Aug 18, 2012 at 23:27
  • 6
    Are you just talking about the naming of the specific exception classes? Then note that in some ecosystems, those are called XYError -- for instance, in Python.
    – user7043
    Commented Aug 18, 2012 at 23:45
  • 6
    Mind you, Java does have an Error class, which inherits from Throwable. See docs.oracle.com/javase/1.4.2/docs/api/java/lang/Error.html for more details. You may also like to check the "Direct Known Subclasses" category.
    – luiscubal
    Commented Aug 19, 2012 at 0:41
  • I would like to say that this conundrum has nothing to do with English. It's more a logical categorization in whichever spoken language in which you choose to be proficient. Commented Aug 19, 2012 at 6:19

14 Answers 14


They don't need to be errors at all. The fact that the page is not there may be just an interesting fact rather than an actual error. They seem to get used as errors almost all the time, I admit. But sometimes they're used to break out of loops, or let you know that a string is not a valid number. They can be used to hold and return vast amounts of useful data--as part of a fairly normal return. (Some languages are a bit slow with their exceptions, in that case throwing them frequently is a bad idea.) In theory anyway, an exception merely means "don't do a normal return, go up the call stack until you find someone interested in this."

Even a null pointer exception might not mean much to you. You call someone else's code, and then catch a null pointer exception because you know it's apt to blow up, print a message saying whose fault it is, and carry on and get your job done.

  • 28
    Although the use of exception mechanisms as control flow can be confusing and I think is generally frowned upon. Commented Aug 18, 2012 at 23:55
  • 11
    @ChaosPandion: Depends on the language/culture.
    – amara
    Commented Aug 19, 2012 at 0:44
  • 12
    @DocBrown: I once wrote a sudoku solver that does recursive search that backtracks when it fails to find the solution in the current attempt and retry with a different value; and when a solution is found, it throws an exception containing the solution. The issue here failure is the "normal" situation, and success is an "exceptional" situation; and since there are multiple points in the solver where it calls itself, without using exception you'd have to write lots of boilerplates for checking whether a call is returning from a successful search or from a failed search.
    – Lie Ryan
    Commented Aug 19, 2012 at 11:37
  • 7
    @Falcon: yes you could just return a 'finished' value, that just means every time you recurse, you're going to have to do: for (...) { if (func() == finished) { return finished; } else { itfailedsocheckanother(); }} but considering that there are multiple points in the code where it is func() is recursing, the exception-less solution gets uglier every time you add more recursion. That is what I call a cargo-cult programming, it is essentially simulating exceptions in a language that already have one because cult leader says "thy shall not use exceptions".
    – Lie Ryan
    Commented Aug 19, 2012 at 16:16
  • 10
    @Falcon: Ah... the stock "it looks like Goto" argument, that arguments works for saying you shouldn't use loops or if statements or function calls, because "they all looks like gotos". Returning success with exception is only a WTF if you're associating exception with errors. For me, when used in this way, a try-catch block is like "a promise to return here after a long journey", the behavior of the try-except+throw is pretty similar to function-calls+returns except it's for a much longer journeys which may involve a very deep call stack when you finished the quest for solution.
    – Lie Ryan
    Commented Aug 19, 2012 at 17:57

The mechanism of exceptions is not always used to signal errors. Exceptions are thrown in out of the ordinary situations that require a separate code path to process, including errors. For example, a user providing a name of a file that does not exist, or entering a letter instead of a digit in a numeric field, are exceptional situations requiring special handling, but these are not errors.

In some programming environments, such as Java, special Error objects are provided to report "true errors", situations that a reasonable application should not attempt to handle. These objects are delivered using the same mechanism that is used for delivering exceptions, but they have a special meaning of signals of unrecoverable situations.


I don't have an etymological research about the origins of that, but I can understand that using the term "Error" may not be precise in all situations; also as almostSharepointMaster mentioned, it is better to think of the error and the exception thrown as separated entities.

When you're in a high-level programing language, it makes sense to assume that an exception is always caused by an error, although I agree also with dasblinkenlight that even then an exception not always is the consequence of an error. I, for instance, use exceptions to terminate threads collaboratively.

The first time I saw the term "exception" was in the 80386 Assembly manual. I remember that when I saw it looked instantly natural to me. To call that an error would not be correct, because there are no errors in Assembly; there are simply conditions the processor can't deal with (if that's an error - from the programmer, the user or the system - well, the processor is completely agnostic to that). I don't know if Intel really originated the term or not, but maybe...


Commonly Exception is used to name an event which is not correct but can be recovered from, like an out_of_range exception in C++, which is thrown when accessing an element in a vector or array that doesn't exist. Clearly such an event is not correct, but it happening shouldn't mean your whole program crashes.

On the other hand errors are usually used to name something that should crash everything, something like a stack overflow is an example of an event that should terminate the program as the program can't handle it internally. In other words: an error is major, while an exception is comparatively minor.


I think this has more to do with "evolution" of error handling. With C/C++ (before exception handling was added) languages, if a function failed, the only way to tell was through the return value (e.g. HRESULT in win32). So typically you ended up catching exit codes of each function call and do a check. This approach makes code messier. And lot of times developers will just avoid adding these checks out of laziness.

With the introduction of exception handling, developers now had two options to raise an error. So the "exception" word was used to distinguish errors from "exit status" errors. After a period of time, exception handling has become a popular way to propagate errors because code is much easier to read, maintain and there can be a single place where you can have error handling logic.


In Python, they are named as ABCError Eg: KeyError, IndexError


So I think it depends on language that you use.

  • 5
    Don't forget VB (classic, not. Net). On Error Goto was used. And the most amazing invention of all time "On Error Resume Next"
    – Kibbee
    Commented Aug 19, 2012 at 14:21
  • 2
    In Python, errors are a subset of exceptions. There are four standard exceptions that inherit from Exception but don't inherit from StandardError: StopIteration, GeneratorExit, KeyboardInterrupt and SystemExit. Commented Aug 20, 2012 at 12:31

When an error occurs, either the system or the currently executing application reports it by throwing an exception containing information about the error. Once thrown, an exception is handled by the application or by the default exception handler.

An error thows an exception that details the error, so not everything is an error that is an exception if that makes sense ;), for instance an noneimplemetedexception shouldnt be an error but thows an exception.



Exceptions and errors are different.

Exceptions are situations a program can overcome, like say you try to open a file and it doesn't exist, while errors are situations a program can't do nothing about, like a disk failure or a RAM failure.

  • Huh? I’d say it’s totally the opposite.
    – gnasher729
    Commented Mar 7, 2022 at 5:53

In iOS/Mac programming, we have both Exceptions and Errors in a single language.

At least in that environment an exception is "non-recoverable", while an error is "recoverable".

For example:

  • if you have an array with 10 items, and you try to access the item at index 30 - that will be an exception. You made a mistake in your programming.
  • if you try to download a URL but there is no internet connection, that is to be expected and you should present some kind of message to the user.

Exceptions typically crash your app, while errors typically return nil and an error object (returned as a by reference method parameter). You can catch exceptions with a try/catch/finally block but it's recommended never to use this language feature - if it is possible to recover from an exception in any way, then you shouldn't be throwing an exception at all (you should return an error object instead).

  • 2
    Well, it is entirely different than what Exception and Errors are meant to the other developers then!
    – Tarik
    Commented Aug 19, 2012 at 5:18
  • Every language is different I guess. Objective-C/Cocoa is one of the oldest languages in active use (from around 1983), so perhaps it's a bit old fashioned. Still, if the definition changes from one community to another it's important to know that. Commented Aug 19, 2012 at 5:21
  • 10 years later: Since Objective-C’s error handling has been moved into Swift and looks quite similar to exceptions while Objective-C exceptions have gone in Swift it doesn’t seem to have anything to do with “old-fashioned”.
    – gnasher729
    Commented Mar 7, 2022 at 5:52

An error is something that has gone wrong in the execution of the program. Often this is dealt with by raising an exception, but

  • there is nothing that forces a programmer to handle an error by raising an exception, and
  • there is nothing that forces a programmer to raise exceptions only in the case of an error.

Error is a semantic concept: it is applied by the programmer or user, who comes to the program with expectations, to describe the difference between their expectations and reality. Only a person can say whether a routine is in an error state or not.

An exception is a syntactic concept: it is something in the program itself, independent of anyone's expectations about what that program is supposed to do. A routine either does or does not raise an exception, regardless of what anyone thinks.


Raising and handling exceptions are control flow features and the name of the exception should follow the intented usage. The designer of code and API should find good and consistent naming schemes.

So the answer to your question is: it depends on the context and perspective.


Exceptions evolved as a generalization of errors. The first programming language to include an exception mechanism was Lisp in the early 1970s. There's a good summary in A Pattern of Language Evolution by Gabriel and Steele. Exceptions (which were not yet called exceptions) arose from the need to specify the behavior of a program if an error occurs. One possibility is to halt the program, but this is not always helpful. Lisp implementations traditionally have had a way to enter the debugger on an error, but sometimes programmers wanted to include error handling in their program. So 1960s Lisp implementations had a way to say “do this, and if an error occurs then do that instead”. Originally errors came from primitive functions, but programmers found it convenient to deliberately trigger an error in order to skip some part of the program and jump to the error handler.

In 1972, the modern form of exception handling in Lisp appeared in MacLisp: throw and catch. The Software Preservation Group lists a lot of material on early Lisp implementations, including The MACLISP Reference Manual Revision 0 by David Moon. The primitives catch and throw are documented in §5.3 p.43.

catch is the LISP function for doing structured non-local exits. (catch x) evaluates x and returns its values, except that if during the evaluation of x (throw y) should be evaluated, catch immediately returns y without further evaluating x.

catch may also be used with a econd argument, not evaluated, which is used as a tag to distinguish between nested catches. (…)

throw is used with catch as a structured nonlocal exit mechanism.

(throw x) evaluates x and throws the value back to the most recent catch.

(throw x <tag>) throws the value of x back to the most recent catch labelled with <tag> or unlabelled.

The focus is on nonlocal control flow. It's a form of goto (an upward-only goto), which is also called a jump. The metaphor is that one part of the program throws the value to return to the exception handler, and the exception handler catches that value and returns it.

Most programming languages today pack the tag and the value in an exception object, and combine the catching mechanism with a handling mechanism.

Exceptions are not necessarily errors. They're a way to exit from a block of code and from the surrounding blocks, escaping until a handler for the exception is reached. Whether such a thing is considered an ”error“ in the intuitive sense is subjective.

Some languages make a distinction between the terms “error” and “exception”. For example, some Lisp dialects have both throw to raise an exception (control flow for users, meant to perform a non-local exit in a way that doesn't indicate that anything went “wrong”) and signal to raise an error (which indicates that something went “wrong” and may trigger a debug event).


You will find it differntly interpreted in different programming language implementations. As dasblinkenlight said that's a java point of view of having a demarcation between Error and Exception. In many programming languages exceptions are violations which can be handled or allowed to be bubbled up to pass on to the highest possible code module. Errors generally are situations where your language's runtime container handles (and many cases just halt the execution).


An error is always an error. An exception is an error in the current context. That is, an exception is context sensitive. An example of an exception would be adding an ascii "a" to an integer "1". An error might be something like using an undefined operator like "+!" in most languages.

Some languges will allow you to Define your way out of the situation if that is really what you want to do.

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