Manejo de excepciones

En informática y programación , el manejo de excepciones es el proceso de responder a la aparición de excepciones —condiciones anómalas o excepcionales que requieren un procesamiento especial— durante la ejecución de un programa . En general, una excepción interrumpe el flujo normal de ejecución y activa un manejador de excepciones preregistrado ; los detalles de cómo se realiza esto dependen de si se trata de una excepción de hardware o de software y de cómo se implementa la excepción de software.

Las excepciones se definen en diferentes capas de un sistema informático. Las capas típicas son las interrupciones definidas por la CPU , las señales definidas por el sistema operativo (SO) y las excepciones definidas por el lenguaje de programación . Cada capa requiere diferentes métodos de manejo de excepciones, aunque pueden estar interrelacionadas; por ejemplo, una interrupción de la CPU podría convertirse en una señal del SO. Algunas excepciones, especialmente las de hardware, pueden manejarse de forma tan eficiente que la ejecución puede reanudarse desde donde se interrumpió.

La definición de excepción se basa en la observación de que cada procedimiento tiene una precondición , un conjunto de circunstancias bajo las cuales terminará "normalmente". ^{[ 1 ]} Un mecanismo de manejo de excepciones permite que el procedimiento genere una excepción ^{[ 2 ]} si se viola esta precondición, ^{[ 1 ]} por ejemplo, si el procedimiento ha sido llamado con un conjunto de argumentos anormal. El mecanismo de manejo de excepciones entonces maneja la excepción. ^{[ 3 ]}

La condición previa y la definición de excepción son subjetivas . El conjunto de circunstancias "normales" lo define completamente el programador; por ejemplo, el programador puede considerar que la división por cero no está definida, por lo tanto, es una excepción, o idear algún comportamiento como devolver cero o un valor especial de "DIVISIÓN POR CERO" (evitando la necesidad de excepciones). ^{[ 4 ]} Las excepciones comunes incluyen un argumento no válido (por ejemplo, el valor está fuera del dominio de una función ), ^{[ 5 ]} un recurso no disponible (como un archivo faltante, ^{[ 6 ]} un error de unidad de red, ^{[ 7 ]} o errores de falta de memoria ^{[ 8 ]} ), o que la rutina haya detectado una condición normal que requiere un manejo especial, por ejemplo, atención, fin de archivo. ^{[ 9 ]} La presión social es una influencia importante en el alcance de las excepciones y el uso de mecanismos de manejo de excepciones, es decir, "ejemplos de uso, que normalmente se encuentran en bibliotecas principales, y ejemplos de código en libros técnicos, artículos de revistas y foros de discusión en línea, y en los estándares de código de una organización". ^{[ 10 ]}

El manejo de excepciones resuelve el problema del semipredicado , ya que el mecanismo distingue los valores de retorno normales de los erróneos. En lenguajes sin manejo de excepciones integrado, como C, las rutinas tendrían que señalar el error de alguna otra manera, como el código de retorno común y el patrón errno . ^{[ 11 ]} Desde una perspectiva amplia, los errores pueden considerarse un subconjunto propio de las excepciones, ^{[ 12 ]} y los mecanismos de error explícitos como errno pueden considerarse formas (verbosas) de manejo de excepciones. ^{[ 11 ]} Se prefiere el término "excepción" a "error" porque no implica que algo esté mal: una condición que un procedimiento o programador considera un error puede no ser considerada así por otro. ^{[ 13 ]}

El término "excepción" puede resultar engañoso porque su connotación de "anomalía" indica que generar una excepción es anormal o inusual, ^{[ 14 ]} cuando, de hecho, generar la excepción puede ser una situación normal y habitual en el programa. ^{[ 13 ]} Por ejemplo, supongamos que una función de búsqueda para un arreglo asociativo genera una excepción si la clave no tiene un valor asociado. Dependiendo del contexto, esta excepción de "clave ausente" puede ocurrir con mucha más frecuencia que una búsqueda exitosa. ^{[ 15 ]}

The first hardware exception handling was found in the UNIVAC I from 1951. Arithmetic overflow executed two instructions at address 0 which could transfer control or fix up the result.^[16] Software exception handling developed in the 1960s and 1970s. Exception handling was subsequently widely adopted by many programming languages from the 1980s onward.

There is no clear consensus as to the exact meaning of an exception with respect to hardware.^[17] From the implementation point of view, it is handled identically to an interrupt: the processor halts execution of the current program, looks up the interrupt handler in the interrupt vector table for that exception or interrupt condition, saves state, and switches control.

Exception handling in the IEEE 754floating-point standard refers in general to exceptional conditions and defines an exception as "an event that occurs when an operation on some particular operands has no outcome suitable for every reasonable application. That operation might signal one or more exceptions by invoking the default or, if explicitly requested, a language-defined alternate handling."

By default, an IEEE 754 exception is resumable and is handled by substituting a predefined value for different exceptions, e.g. infinity for a divide by zero exception, and providing status flags for later checking of whether the exception occurred (see C language revision C99 for a typical example of handling of IEEE 754 exceptions). An exception-handling style enabled by the use of status flags involves: first computing an expression using a fast, direct implementation; checking whether it failed by testing status flags; and then, if necessary, calling a slower, more numerically robust, implementation.^[18]

The IEEE 754 standard uses the term "trapping" to refer to the calling of a user-supplied exception-handling routine on exceptional conditions, and is an optional feature of the standard. The standard recommends several usage scenarios for this, including the implementation of non-default pre-substitution of a value followed by resumption, to concisely handle removable singularities.^[18][19][20]

El comportamiento predeterminado de manejo de excepciones IEEE 754, que consiste en reanudar la ejecución tras la sustitución previa de un valor predeterminado, evita los riesgos inherentes al cambio del flujo de control del programa ante excepciones numéricas. Por ejemplo, el lanzamiento de la nave espacial Cluster en 1996 terminó en una explosión catastrófica, debida en parte a la política de manejo de excepciones de Ada , que abortaba el cálculo ante un error aritmético. William Kahan afirma que el comportamiento predeterminado de manejo de excepciones IEEE 754 lo habría evitado. ^{[ 19 ]}

Los frameworks de desarrollo web front-end , como React y Vue , han introducido mecanismos de manejo de errores donde los errores se propagan hacia arriba en la jerarquía de componentes de la interfaz de usuario (UI), de forma análoga a como se propagan los errores en la pila de llamadas durante la ejecución del código. ^{[ 21 ] [ 22 ]} Aquí, el mecanismo de límite de error sirve como análogo al mecanismo try-catch típico. De esta manera, un componente puede asegurar que los errores de sus componentes hijos se capturen y manejen, y no se propaguen a los componentes padres.

Por ejemplo, en Vue.js , un componente capturaría errores mediante la implementaciónerrorCaptured

Vue.component('parent',{template: '<div><slot></slot></div>',errorCaptured:(err,vm,info)=>alert('An error occurred'); }) Vue.component('child',{template: '<div>{{cause_error()}}</div>' }) 

Cuando se utiliza de esta manera en el marcado:

<padre> <hijo> </hijo> </padre>​​​​​​​

El error producido por el componente hijo es capturado y manejado por el componente padre. ^{[ 23 ]}

• Triple falta
• Validación de datos
• Sistema de efectos