En segundo lugar, me preguntaba si alguien sabía cuál era la diferencia entre las excepciones (en el ámbito del flujo de control de excepciones) y las Excepciones (como las que se usan en Java).
¿Pero están allí para proteger básicamente el sistema de fallas al finalizar el programa de usuario?
Respuestas:
Existen excepciones para permitir el manejo de excepciones , que pueden evitar bloqueos pero, en general, evitan comportamientos no deseados o impredecibles del sistema. Por ejemplo, si se agota el tiempo de espera de la conexión de mi programa a una base de datos, generalmente no se bloqueará el sistema, pero si dependiera de los datos de la base de datos, una excepción puede permitirme tratar esta situación sin datos de manera diferente de lo normal.
Digamos que, de manera predeterminada, mi programa muestra una página de datos en función de lo que se devolvió de la base de datos: bueno, no tengo datos. En lugar de presentar una vista desordenada o continuar una operación potencialmente inválida, puedo detectar esta excepción y recurrir a una base de datos diferente, leer datos locales, pedir datos al usuario o devolver el usuario o el sistema a un estado seguro (presumiblemente uno ¡eso no causará inmediatamente la misma excepción!)
Además, en los sistemas donde la entrada del usuario podría ser la causa / solución de un problema, las excepciones pueden permitirle al usuario conocer información detallada y útil sobre el problema. En lugar del demasiado común "Se produjo una excepción no controlada en ..." o "Mensaje de error intimidante directo de SQL", puede decirle al usuario algo útil o al menos comprensible como "No se pudo conectar al recurso B".
Se crearon excepciones para simplificar el manejo de errores. Sin excepciones, la lógica de manejo de errores debe extenderse a través de una aplicación. Cualquier función que pueda dar lugar a un error debe de alguna manera devolver un estado de error, y cada llamada debe ir seguida de una verificación de error. A menudo, la persona que llama no puede hacer nada útil en caso de error, y solo puede devolver un error. La mitad del código de la aplicación puede dedicarse al manejo de errores. Tal código es extremadamente frágil. Es muy fácil dejar de lado una comprobación de errores y bloquearse, o peor aún, devolver resultados incorrectos debido a un error inadvertido.
Con excepciones, los errores pueden verificarse solo en el punto donde pueden manejarse. La mayoría del código de la aplicación se puede escribir en línea recta, ya que las funciones devolverán un valor utilizable o arrojarán una excepción.
El punto de una excepción debe ser informar al usuario de circunstancias excepcionales. Si algo sale mal con el sistema, el programa debe saberlo y se le debe permitir manejarlo * adecuadamente.
Dicho esto, no, no existe una excepción para evitar que el sistema se "bloquee". Una excepción es que me está haciendo saber que hay un problema. Cómo procedo determina puede determinar si el sistema "se bloquea".
También tenga en cuenta que una excepción no tiene que terminar una aplicación como usted ha dicho. El programador puede manejar una excepción y corregirla o convertirla en un error significativo para el usuario.
* El uso de excepciones marcadas (excepciones que son forzadas a ser atrapadas) es un poco doloroso. Algunos (tal vez la mayoría) los desarrolladores encuentran que el manejo forzado de excepciones es engorroso, innecesario y simplemente una mala práctica.
Las excepciones permiten el manejo moderno de errores al dividir la ubicación del error del controlador de errores. A veces esto también se usa para el control de flujo.
Las excepciones no manejadas terminan un programa. Pero estas no son diferentes de las excepciones anteriores, solo un programador perezoso que olvidó incluir controladores de errores adecuados en cada ruta los hace visibles para el usuario final. Considero que un programa terminado por excepción se bloqueó igual que cualquier otro final inesperado.
Los sistemas operativos son muy buenos para limpiar los procesos bloqueados, sin importar cómo se bloquearon, por lo que las excepciones no agregan seguridad para el sistema operativo de otra manera que no sea terminar los procesos defectuosos y liberar sus recursos.
Es muy simple.
Antes de que se inventaran las excepciones, cada función tenía que devolver un código de salida (error / éxito) y cualquier resultado o salida de la función tenía que recuperarse pasándole un puntero a la memoria para que lo configurara.
El problema era que muchos programadores no recordaban ni se molestaban en buscar códigos de salida erróneos para cada función y, por lo tanto, a veces se ignoraban los errores fatales, lo que conducía a comportamientos inexplicables.
Por lo tanto, se decidió: cuando ocurre un error, que no tuvo en cuenta, ¡se bloquea de inmediato! Manejo de excepciones AKA.
Las excepciones son simplemente un mecanismo de detección de errores. Por sí mismos no sirven de nada.
Pero al detectar un error, permiten activar mecanismos de tolerancia a fallas para recuperarse del estado erróneo al cambiar a un estado libre de errores (un estado anterior o uno nuevo). De esa forma, el error no se propaga a otras partes del sistema.
Existen excepciones para separar el flujo normal del programa (para lo que está diseñado el programa) del flujo de manejo de errores (cómo el programa intenta recuperarse de una situación excepcional).
Esto hace que el código sea más claro y más fácil de mantener.
Considere dos fragmentos de código:
try:
do1() # this is obvoiusly a normal
do2() # program flow
except:
oups() # this is exception handling code
En comparación con este:
if foo():
thing1() # is this part of normal program flow?
else:
thing2() # or maybe this one? Or both? When?
Por supuesto, el manejo de excepciones se puede utilizar para evitar que el programa falle:
try { // very bad code
my();
whole();
ugly();
application();
here();
} catch (Throwable t) {
// pretend it's ok
}
pero esta no es la razón de las excepciones en los lenguajes de programación modernos.
También puede usar whiley en breaklugar de, ifpero esto no es para qué whiley breakpara qué .