Más información sobre las excepciones y cómo escribir mejor manejo de errores de código. Castalia aprender cómo nos puede ayudar a escribir más robusto y con tolerancia a errores de código.
(Originalmente publicado en Delphi-expert.com el 23 de marzo de 2004)
Como se prometió, hoy es parte de nuestro debate de Delphi de intentar construcciones. La semana pasada, nos miró finalmente intentar .., Se enteró de lo que se destina para, cuando su uso, Castalia y cómo nos pueden ayudar a utilizarlo de manera más eficaz. Esta semana, vamos a examinar la otra mitad de la familia intentar, intentar .. salvo y aprender cómo Castalia puede intentar hacer de nuestra .. salvo el uso más eficaz. También se burlan de java.
Pruebe con excepción ..es una construcción para el manejo de "excepcional" en situaciones de un programa. Un programa típico tiene una corriente, que es un conjunto de instrucciones que proceder en orden. A veces esto implica para las sucursales, pero siempre hay un flujo lógico, y las decisiones que la rama de flujo se basan en algunos estado del programa, al igual que si X es inferior a 5.
A veces, sin embargo, que el Estado puede ser incorrecta. Tomemos un ejemplo que podemos ver en el mundo real:
AssignFile (F, 'SomeFile.Txt');
ResetFile (F);
S: = ReadLn (F);
Closefile (F);
Este simple código se abrirá un archivo, leer una línea de él, y cerrarlo de nuevo. Este es el flujo normal del programa. Sin embargo, una serie de hipótesis se hacen acerca de este flujo. En primer lugar, suponemos que el archivo existe. Suponemos que podemos abrir para lectura. Suponemos que hay una línea que debe leer. Etc ..
Si ninguna de estas hipótesis resulta ser falsa, entonces tenemos una situación excepcional! El flujo del programa va a ser desordenado por el hecho de que algunos Estados no es el estado de lo que esperábamos.
Hay varias formas de manejar estas situaciones excepcionales. Podemos hacer caso omiso de ellos, y si alguno de ellos se produce, el programa se colgará o hacer otra cosa igualmente errático. Hemos podido comprobar de esas excepciones, la adición de código como este:
si no Fileexists ( 'SomeFile.txt') entonces
empezar
WriteLn ( 'El archivo no existe');
Exit;
final;
Esto es mejor. Por un lado, usted tiene realmente el usuario le dijo por qué el programa no funcionará. Para los programas de simple, esto funciona bien, pero como el programa se vuelve más y más complejas, el estado del programa será exponencial compleja, y pronto no se podrá comprobar todas las hipótesis. Comprobar su hipótesis es una buena cosa, aunque. Vamos a volver a esto más tarde.
También podemos checkafter cada operación para asegurarse de que lo que espera que esto ocurra. Este es el enfoque tradicional C, y el enfoque de la API de Windows (y la mayoría de los demás APIs del sistema operativo, con BeOS como una notable excepción). En este modelo, cada función devuelve un código de error. Es su responsabilidad comprobar el código de error y ver si es "OK" o alguna otra cosa como FILE_NOT_FOUND. Luego, una vez más, le informará al usuario y de salida.
Esto es, al final, una variación sobre el mismo enfoque, sólo que esta vez estamos comprobando las hipótesis después de hacer algo, en lugar de antes. La ventaja es que cada función puede controlar su propia hipótesis, y en el caso de la API de Windows, todos los posibles valores de retorno son muy bien documentadas, de modo disciplinado con la escritura, en realidad es posible manejar todas las condiciones, en el supuesto de que quien escribió la API tomó todas sus hipótesis en consideración. Código escrito con este enfoque se vería algo como esto (No, esto no es válido Pascal, mis disculpas a los puristas):
ErrCode: AssignFile = (F, 'SomeFile.Txt');
si ErrCode = FILE_NOT_FOUND entonces
empezar
WriteLn ( 'No se encuentra el archivo');
Exit;
final;
ErrCode: ResetFile = (F);
si ErrCode = FILE_NO_ACCESS entonces
empezar
WriteLn ( 'Usted don''t tienen acceso a hacer eso. ");
Exit;
end else
si ErrCode = FILE_ALREADY_OPEN entonces
empezar
WriteLn ( 'Alguien está leyendo el fichero');
Exit;
final;
ErrCode: ReadLn = (F, S); / / Supongamos que esto significa leer en F de S
si ErrCode = NOT_ENOUGH_TEXT entonces
empezar
WriteLn ( 'No hay suficiente Texto');
Exit;
final;
Closefile (F);
Usted consigue la idea. Podría ser mucho peor, pero nuestro programa ha llegado realmente compleja realidad rápidamente, y para dar cabida a todas las cosas que no suelen suceder.
Así pues, alguien en el último par de décadas con una nueva idea. ¿Por qué no crear una estructura de control específicamente para situaciones excepcionales? Esta nueva estructura de control podría nos permitiría definir lo que debería suceder normalmente y, a continuación, definir lo que debería pasar si algo sale mal. Esto se conoce como "manejo de excepciones".
La idea básica detrás de una excepción es que suponemos que el flujo normal de control va a tener lugar. Si no es así, que al instante para la ejecución de lo que somos y salir de la actual función. A continuación, salir de la función que llamó esa función, y así sucesivamente, hasta llegar a un manejador de excepción, que es un bloque de código que se ejecuta sólo cuando un estado excepcional o evento tiene lugar. Si el flujo normal de ejecución es seguida, manejadores de excepción se ignoran.
En Delphi, el flujo normal de ejecución se encuentra en un bloque try, y el manejador de excepción es, salvo en un bloque. He aquí un simple ejemplo:
intentar
AssignFile (F, 'SomeFile.txt');
ResetFile (F);
S: = ReadLn (F);
Closefile (F);
excepto
WriteLn ( 'Se ha producido un error');
final;
Esto es más limpia, y lo que nos permite ver claramente lo que esperamos que el código que se ejecuta normalmente, y lo que el código debe ser ejecutado cuando ocurre algo extraño (no como el último ejemplo estremezco ...).
Por supuesto, sería bueno poder decirle al usuario exactamente lo que se ha producido un error. Excepción a esta manipulación de una brisa también. Desde el manejo de excepciones desarrollado de la mano con la programación orientada a objetos, cosas llamadas excepción objetos fueron concebidos. La excepción objeto se crea automáticamente una excepción cuando se plantea. Si queremos usar el objeto excepción, que intenta ampliar la excepción de la sintaxis .. como esta:
intentar
AssignFile (F, 'SomeFile.txt');
ResetFile (F);
S: = ReadLn (F);
Closefile (F);
excepto
sobre E: Exception do
WriteLn (E. Mensaje);
final;
Verás, cada excepción tiene un mensaje de la propiedad que da una breve información útil acerca de la excepción específica. Se puede contener la cadena "Archivo no encontrado" o "archivo ya en uso", o algo que nos gustaría decirle al usuario.
Existen diferentes tipos de excepciones, y podemos aprovechar de eso también. Tal vez queremos hacer algo especial cuando uno pasa cierta excepción. Tal vez queremos pitido si el archivo no se encuentra:
intentar
AssignFile (F, 'SomeFile.txt');
ResetFile (F);
S: = ReadLn (F);
Closefile (F);
excepto
sobre E: Filenotfound hacer
Beep;
sobre E: Exception do
WriteLn (E. Mensaje);
final;
Tenga en cuenta que cuando se manejan múltiples excepciones, la mayoría de la excepción específica debe ir primero. Esto se debe a que las excepciones son polimórficos - es decir, la excepción es cada excepción, y EFileNotFound es una excepción, por lo que si se trata de excepciones en primer lugar, EFileNotFound nunca será manipulado.
Un problema con este mecanismo es que estamos todavía no está seguro de lo que un particular excepciones función o procedimiento podría plantear. Algunos idiomas o herramientas de desarrollo de un mecanismo que le ayudará a saber lo que se podrían plantear. Una IDE de C #, por ejemplo, le dará una pista pequeña ventana que te diga lo que las excepciones que deberán manejar cuando se utiliza una función. Java es famoso (y odiado por muchos) por el hecho de que vela por el cumplimiento de manejo de excepciones con celo terroristas. El código no compila incluso si no se manejan las excepciones que se quiere que, incluso si usted sabe que esas excepciones no se va a pasar, ya sea porque usted tiene el control sobre el entorno de ejecución, o su código ya ha prechecked la condición y garantizar que la excepción no pueden ser arrojados. Java hará cumplir su código de estilo para anotar el último título y, si te gusta o no.
Lamentablemente, no existe una herramienta para Delphi. Mientras escribo esto, me estoy empezando a pensar que podría ser una buena cosa que añadir a Castalia. Voy a tener que mirar en eso.
¡Menos mal!
Eso fue tres y media páginas de Microsoft Word, sólo para entender lo que es una excepción. Ahora para la diversión cosas:
Castalia puede ayudarle a escribir su normal tanto código y su código de manejo de excepción. Castalia el código de las plantillas de trye definir una plantilla que crea automáticamente unintenta bloquear .. excepto para usted y establece los puntos de entrada de modo que usted pueda crear correctamente el código. Esto le ahorrará más las pulsaciones de teclado y más tiempo del que te das cuenta!
Castalia de la refactorización herramientas automatizadas proporcionan un sonido envolvente con ...refactoring que se intenta poner un bloque .. excepto alrededor de su código. Sólo destacar el flujo normal de control de código, haga clic derecho sobre el editor (o pulse Ctrl + Mayúsculas + R), y elegir el elemento adecuado de la refactorización menú. El código será cambiado automáticamente.
Esta semana, hemos aprendido lo que el intentar .. excepto bloque y de dónde vino (y por qué es el mejor mecanismo de gestión de errores todavía). También hemos aprendido cómo Castalia puede hacer uso de esta potente estructura de control para escribir más robusto y fácil de usar código.
Para obtener más información acerca de Castalia el código de las plantillas, haga clic aquí.
Para obtener más información acerca de Castalia refactorings automatizado, haga clic enaquí
Para comprar Castalia, ya que el artículo era la mejor cosa que nunca han leído, haga clic aquí, a continuación, haga clic aquí para leer un libro mucho mejor.
Delicious
Digg
Google
Yahoo
