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

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 los bucles o para hacerle saber que una cadena no es un número válido. Se pueden usar para retener y devolver grandes cantidades de datos útiles, como parte de un rendimiento bastante normal. (Algunos idiomas son un poco lentos con sus excepciones, en ese caso, lanzarlos con frecuencia es una mala idea). En teoría, de todos modos, una excepción simplemente significa "no hagas un retorno normal, sube el número de llamadas hasta que encuentres a alguien interesado". en esto. "

Incluso una excepción de puntero nulo puede no significar mucho para ti. Llama al código de otra persona y luego atrapa una excepción de puntero nulo porque sabe que es probable que explote, imprima un mensaje que indique quién es el culpable y continúe y haga su trabajo.

El mecanismo de excepciones no se usa siempre para señalar errores. Se lanzan excepciones fuera de las situaciones ordinarias que requieren una ruta de código por separado 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 tratamiento especial, pero no son errores.

En algunos entornos de programación, como Java, especial Error para informar "errores verdaderos", situaciones que una aplicación razonable no debe tratar de manejar. Estos objetos se entregan utilizando 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 usar el término "Error" puede no ser preciso en todas las situaciones; Además, como casi se mencionó ShareepointMaster, es mejor pensar en el error y la excepción lanzada como entidades separadas.

Cuando estás 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 una excepción no siempre es la consecuencia de un error. Yo, por ejemplo, uso excepciones para terminar los hilos de forma colaborativa.

La primera vez que vi el término "excepción" fue en el manual de montaje 80386. Recuerdo que cuando lo vi me pareció al instante natural. Llamar a eso un error no sería correcto, porque no hay errores en el montaje; 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 ajeno a eso). No sé si Intel realmente originó el término o no, pero quizás ...

Comúnmente se usa la excepción para nombrar un evento que no es correcto pero se puede recuperar, como una excepción out_of_range en C ++, que se produce cuando se accede a un elemento en un vector o matriz que no existe. Claramente, tal evento no es correcto, pero esto no debería significar que todo tu programa se cuelgue.

Por otro lado, los errores generalmente se usan para nombrar algo que debería bloquear todo, algo así 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 comparativamente 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 fallaba una función, la única forma de saberlo era a través del valor de retorno (por ejemplo, HRESULT en win32). Así que, por lo general, terminas atrapando los códigos de salida de cada función y realizas una verificación. Este enfoque hace que el código sea más complicado. Y muchas veces los desarrolladores simplemente evitan agregar estos controles por pereza.

Con la introducción del manejo de excepciones, los desarrolladores ahora tenían dos opciones para generar un error. Así que la palabra "excepción" se usó 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 y mantener, y puede haber un solo lugar donde pueda tener lógica de manejo de errores.

En Python, se nombran como ABCError Por ejemplo: KeyError, IndexError

enlace

Así que creo que depende del idioma que uses.

Cuando se produce un error, el sistema o la aplicación que se está ejecutando en ese momento lo reportan al lanzar una excepción que contiene información sobre el error. Una vez lanzada, la aplicación o el controlador de excepciones predeterminado manejan una excepción.

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 implemeted no debería ser un error pero sí una excepción.

enlace

En la programación de 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, eso será una excepción. Cometiste un error en tu programación.
• si intenta descargar una URL pero no hay conexión a Internet, es de esperar y debe presentar algún tipo de mensaje al usuario.

Las excepciones suelen bloquear su aplicación, mientras que los errores generalmente devuelven nil y un objeto de error (devuelto como un parámetro del método de referencia). Puede detectar excepciones con un bloque try / catch / finally pero se recomienda nunca usar esta función de idioma. Si es posible recuperar una excepción de alguna manera, entonces no debería lanzar una excepción en absoluto (debería devolver un objeto de error en su lugar).

Un error es algo que ha fallado en la ejecución del programa. A menudo, esto se resuelve con una excepción , pero

• no hay nada que obligue a un programador a manejar un error al generar 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 : lo aplica 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 un estado de error o no.

Una excepción es un concepto sintáctico : es algo en el programa en sí mismo, independientemente de las expectativas de cualquiera sobre lo que se supone que debe hacer ese programa. Una rutina o no genera 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 el uso intencionado. El diseñador de código y API debe encontrar esquemas de nombres buenos y consistentes.

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

Las excepciones evolucionaron como una generalización de errores. El primer lenguaje de programación de para incluir un mecanismo de excepción fue Lisp a principios de los años setenta. Hay un buen resumen en A Pattern of Language Evolution por Gabriel and Steele . Las excepciones (que aún no se llamaban 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 al depurador en un error, pero a veces los programadores querían incluir el manejo de errores en su programa. Así que las implementaciones de Lisp en la década de 1960 tenían una manera 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 desencadenar deliberadamente un error para omitir una parte del programa y saltar al controlador de errores.

En 1972, la forma moderna de manejo de excepciones en Lisp apareció en MacLisp: throw y catch . El Software Preservation Group enumera una gran cantidad de material sobre las primeras implementaciones de Lisp, incluyendo El Manual de referencia MACLISP Revisión 0 por David Moon . Las primitivas catch y throw se documentan en §5.3 p.43.

  

catch es la función LISP para realizar salidas estructuradas no locales. (catch x) evalúa x y devuelve sus valores, excepto que si durante la evaluación de x (throw y) se debe evaluar, catch devuelve y sin evaluar más x .

     

catch también se puede usar con un segundo argumento, no evaluado, que se usa como una etiqueta para distinguir entre las capturas anidadas. (…)

     

throw se usa con catch como un mecanismo de salida no local estructurado.

     

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

     

(throw x <tag>) devuelve el valor de x al catch más reciente etiquetado 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 conoce como 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 de hoy empaquetan 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 Lisp tienen throw para generar una excepción (flujo de control para los usuarios, destinado a realizar una salida no local de manera que no indique que algo haya salido "mal") y signal para aumentar 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 java para 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 burbujeen para pasar al módulo de código más alto posible. Los errores generalmente son situaciones en las que el contenedor de tiempo de ejecución de su idioma se maneja (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 un ascii "a" a un entero "1". Un error podría ser algo así como usar un operador no definido como "+!" en la mayoría de los idiomas.

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