Take the 2-minute tour ×

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 me this. Why is it named as Exception but not Error since they are errors.

It could be PageNotFoundErrorinstead of PageNotFoundException.

share|improve this question
Not all exceptional situations are errors. –  Andrew Finnell Aug 18 '12 at 23:23
It's the difference between swerving the car and crashing the car. –  World Engineer Aug 18 '12 at 23:27
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. –  delnan Aug 18 '12 at 23:45
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 Aug 19 '12 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. –  Blessed Geek Aug 19 '12 at 6:19

12 Answers 12

up vote 52 down vote accepted

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.

share|improve this answer
Although the use of exception mechanisms as control flow can be confusing and I think is generally frowned upon. –  ChaosPandion Aug 18 '12 at 23:55
@ChaosPandion: Depends on the language/culture. –  naiad Aug 19 '12 at 0:44
@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 Aug 19 '12 at 11:37
@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 Aug 19 '12 at 16:16
@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 Aug 19 '12 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.

share|improve this answer

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...

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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


So I think it depends on language that you use.

share|improve this answer
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 Aug 19 '12 at 14:21
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. –  Dirk Holsopple Aug 20 '12 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.


share|improve this answer

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).

share|improve this answer
Well, it is entirely different than what Exception and Errors are meant to the other developers then! –  Tarik Aug 19 '12 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. –  Abhi Beckert Aug 19 '12 at 5:21

Exceptions and error 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.

share|improve this answer

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.

share|improve this answer

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).

share|improve this answer

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.

share|improve this answer

Your Answer


