¿Por qué los errores se denominan "Excepción" pero no "Error" en los lenguajes de programación?

He estado pensando en eso durante bastante tiempo en realidad. No soy hablante nativo de inglés, pero todavía tengo años de experiencia en programación y siempre me lo pregunté. ¿Por qué se llama Excepción pero no Error, ya que son errores?

Podría ser en PageNotFoundErrorlugar de PageNotFoundException.

No necesitan ser errores en absoluto. El hecho de que la página no esté allí puede ser solo un hecho interesante en lugar de un error real. Parece que se utilizan como errores casi todo el tiempo, lo admito. Pero a veces se usan para romper bucles o hacerle saber que una cadena no es un número válido. Se pueden usar para guardar y devolver grandes cantidades de datos útiles, como parte de un retorno bastante normal. (Algunos idiomas son un poco lentos con sus excepciones, en ese caso arrojarlos con frecuencia es una mala idea). En teoría, de todos modos, una excepción simplemente significa "no hagas un retorno normal, sube la pila de llamadas hasta que encuentres a alguien interesado en esto."

Incluso una excepción de puntero nulo podría no significar mucho para usted. Llama al código de otra persona y luego detecta una excepción de puntero nulo porque sabe que es probable que explote, imprima un mensaje que indique de quién es la culpa y continúe y haga su trabajo.

El mecanismo de excepciones no siempre se usa para señalar errores. Se generan excepciones fuera de las situaciones ordinarias que requieren una ruta de código separada para procesar, incluidos los errores. Por ejemplo, un usuario que proporciona un nombre de un archivo que no existe, o que ingresa una letra en lugar de un dígito en un campo numérico, son situaciones excepcionales que requieren un manejo especial, pero estos no son errores.

En algunos entornos de programación, como Java, Errorse proporcionan objetos especiales para informar "errores verdaderos", situaciones que una aplicación razonable no debería intentar manejar. Estos objetos se entregan usando el mismo mecanismo que se usa para entregar excepciones, pero tienen un significado especial de señales de situaciones irrecuperables.

No tengo una investigación etimológica sobre los orígenes de eso, pero puedo entender que el uso del término "Error" puede no ser preciso en todas las situaciones; También, como casi menciona ShareShareMaster, es mejor pensar en el error y la excepción lanzada como entidades separadas.

Cuando se encuentra en un lenguaje de programación de alto nivel, tiene sentido suponer que una excepción siempre es causada por un error, aunque también estoy de acuerdo con dasblinkenlight en que incluso entonces una excepción no siempre es la consecuencia de un error. Yo, por ejemplo, uso excepciones para terminar hilos en colaboración.

La primera vez que vi el término "excepción" fue en el manual de montaje 80386. Recuerdo que cuando lo vi me pareció instantáneamente natural. Llamar a eso un error no sería correcto, porque no hay errores en el ensamblado; simplemente hay condiciones con las que el procesador no puede lidiar (si eso es un error, del programador, del usuario o del sistema, bueno, el procesador es completamente independiente de eso). No sé si Intel realmente originó el término o no, pero tal vez ...

Comúnmente, Exception se usa para nombrar un evento que no es correcto pero que se puede recuperar, como una out_of_rangeexcepción en C ++, que se genera al acceder a un elemento en un vector o matriz que no existe. Claramente, tal evento no es correcto, pero suceder no debería significar que todo el programa se bloquee.

Por otro lado, los errores generalmente se usan para nombrar algo que debería bloquear todo, algo como un desbordamiento de pila es un ejemplo de un evento que debería terminar el programa ya que el programa no puede manejarlo internamente. En otras palabras: un error es mayor, mientras que una excepción es relativamente menor.

Creo que esto tiene más que ver con la "evolución" del manejo de errores. Con los lenguajes C / C ++ (antes de que se agregara el manejo de excepciones), si una función fallaba, la única forma de saberlo era a través del valor de retorno (por ejemplo, HRESULTen win32). Por lo general, terminaste capturando códigos de salida de cada llamada de función y haciendo una verificación. Este enfoque hace que el código sea más desordenado. Y muchas veces los desarrolladores simplemente evitarán agregar estos cheques por pereza.

Con la introducción del manejo de excepciones, los desarrolladores ahora tenían dos opciones para generar un error. Entonces, la palabra "excepción" se utilizó para distinguir los errores de los errores de "estado de salida". Después de un período de tiempo, el manejo de excepciones se ha convertido en una forma popular de propagar errores porque el código es mucho más fácil de leer, mantener y puede haber un solo lugar donde puede tener lógica de manejo de errores.

En Python, se nombran como ABCError Ej: KeyError, IndexError

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

Así que creo que depende del idioma que uses.

Cuando se produce un error, el sistema o la aplicación que se está ejecutando actualmente lo informa lanzando una excepción que contiene información sobre el error. Una vez lanzada, la aplicación maneja una excepción o el manejador de excepciones predeterminado.

Un error arroja una excepción que detalla el error, por lo que no todo es un error que es una excepción si eso tiene sentido;), por ejemplo, una excepción no simple no debería ser un error pero arroja una excepción.

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

En la programación iOS / Mac, tenemos tanto Excepciones como Errores en un solo idioma.

Al menos en ese entorno, una excepción es "no recuperable", mientras que un error es "recuperable".

Por ejemplo:

• Si tiene una matriz con 10 elementos e intenta acceder al elemento en el índice 30, será una excepción. Cometiste un error en tu programación.
• si intenta descargar una URL pero no hay conexión a Internet, eso es de esperar y debe presentar algún tipo de mensaje al usuario.

Las excepciones normalmente bloquean su aplicación, mientras que los errores generalmente regresan nily un objeto de error (devuelto como un parámetro por método de referencia). Puede detectar excepciones con un bloque try / catch / finally pero se recomienda nunca usar esta función de lenguaje: si es posible recuperarse de una excepción de alguna manera, entonces no debería lanzar una excepción en absoluto (debe regresar un objeto de error en su lugar).

Un error es algo que salió mal en la ejecución del programa. A menudo, esto se trata planteando una excepción , pero

• no hay nada que obligue a un programador a manejar un error generando una excepción, y
• no hay nada que obligue a un programador a generar excepciones solo en caso de error.

El error es un concepto semántico : es aplicado por el programador o usuario, que llega al programa con expectativas, para describir la diferencia entre sus expectativas y la realidad. Solo una persona puede decir si una rutina está en estado de error o no.

Una excepción es un concepto sintáctico : es algo en el programa en sí mismo, independiente de las expectativas de cualquier persona sobre lo que se supone que debe hacer ese programa. Una rutina genera o no una excepción, independientemente de lo que piensen los demás.

Las excepciones y los errores son diferentes.

Las excepciones son situaciones que un programa puede superar, como decir que intenta abrir un archivo y no existe, mientras que los errores son situaciones sobre las que un programa no puede hacer nada, como una falla de disco o una falla de RAM.

Las excepciones de aumento y manejo son características de flujo de control y el nombre de la excepción debe seguir al uso previsto. El diseñador de código y API debe encontrar esquemas de nombres buenos y consistentes.

Entonces la respuesta a su pregunta es: depende del contexto y la perspectiva.

Las excepciones evolucionaron como una generalización de errores. El primer lenguaje de programación que incluyó un mecanismo de excepción fue Lisp a principios de la década de 1970. Hay un buen resumen en A Pattern of Language Evolution por Gabriel y Steele. Las excepciones (que aún no se llamaron excepciones) surgieron de la necesidad de especificar el comportamiento de un programa si se produce un error. Una posibilidad es detener el programa, pero esto no siempre es útil. Las implementaciones de Lisp tradicionalmente han tenido una forma de ingresar el depurador en un error, pero a veces los programadores querían incluir el manejo de errores en su programa. Entonces, las implementaciones de Lisp en la década de 1960 tenían una forma de decir "haz esto, y si ocurre un error, hazlo en su lugar". Originalmente, los errores provenían de funciones primitivas, pero los programadores consideraron conveniente activar deliberadamente un error para omitir alguna parte del programa y saltar al controlador de errores.

En 1972, la forma moderna de manejo de excepciones en Lisp apareció en MacLisp: throwy catch. El Grupo de preservación de software enumera una gran cantidad de material sobre las primeras implementaciones de Lisp, incluida la Revisión 0 del Manual de referencia MACLISP de David Moon . Las primitivas catchy throwse documentan en §5.3 p.43.

catches la función LISP para hacer salidas estructuradas no locales. (catch x)evalúa xy devuelve sus valores, excepto que si durante la evaluación de x (throw y)debe evaluarse, catchdevuelve inmediatamente ysin más evaluaciones x.

catchtambién se puede usar con un argumento econd, no evaluado, que se usa como etiqueta para distinguir entre capturas anidadas. (...)

throwse utiliza con catchun mecanismo estructurado de salida no local.

(throw x)evalúa xy devuelve el valor al más reciente catch.

(throw x <tag>)arroja el valor de xnuevo al más reciente catchetiquetado con <tag>o sin etiquetar.

El foco está en el flujo de control no local . Es una forma de goto (un goto solo hacia arriba), que también se llama salto . La metáfora es que una parte del programa arroja el valor para volver al controlador de excepciones, y el controlador de excepciones captura ese valor y lo devuelve.

La mayoría de los lenguajes de programación hoy empacan la etiqueta y el valor en un objeto de excepción, y combinan el mecanismo de captura con un mecanismo de manejo.

Las excepciones no son necesariamente errores. Son una forma de salir de un bloque de código y de los bloques circundantes, escapando hasta que se alcanza un controlador para la excepción. Si tal cosa se considera un "error" en el sentido intuitivo es subjetivo.

Algunos idiomas hacen una distinción entre los términos "error" y "excepción". Por ejemplo, algunos dialectos de Lisp tienen throwque generar una excepción (flujo de control para los usuarios, destinado a realizar una salida no local de una manera que no indica que algo salió "mal") y signalgenerar un error (que indica que algo salió "mal" y puede desencadenar un evento de depuración).

Lo encontrará interpretado de manera diferente en diferentes implementaciones de lenguaje de programación. Como dijo Dasblinkenlight, ese es un punto de vista de Java de tener una demarcación entre Error y Excepción. En muchos lenguajes de programación, las excepciones son infracciones que se pueden manejar o permitir que se hagan burbujas para pasar al módulo de código más alto posible. Los errores generalmente son situaciones en las que se maneja el contenedor de tiempo de ejecución de su idioma (y muchos casos simplemente detienen la ejecución).

Un error siempre es un error. Una excepción es un error en el contexto actual. Es decir, una excepción es sensible al contexto. Un ejemplo de una excepción sería agregar una ascii "a" a un entero "1". Un error podría ser algo como usar un operador indefinido como "+!" en la mayoría de los idiomas

Algunos idiomas te permitirán definir tu salida de la situación si eso es realmente lo que quieres hacer.