Why are errors named as “Exception” but not as “Error” in programming languages?

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.

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.

http://msdn.microsoft.com/en-us/library/system.exception.aspx

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

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

http://docs.python.org/library/exceptions.html

So I think it depends on language that you use.

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

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.

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

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.

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.

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.