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.

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

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

So I think it depends on language that you use.

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

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.

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

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.