iphone - propagacion - tipos de excepciones en programacion
Práctica de manejo de excepciones de prueba y captura para iPhone/Objective-C (2)
La respuesta de @bbum es absolutamente correcta (y él sabría la respuesta mejor que la mayoría). Para elaborar un poco ...
En Cocoa, generalmente debe evitar el uso de excepciones ( @try/@catch[/@finally] ) para el control de flujo. Como mencionó, las excepciones tienen un costo inusualmente alto (en comparación con los tiempos de ejecución como JVM o CLR optimizado para el uso de excepciones). Además, la mayoría de los marcos de Cocoa no son una excepción segura. Por lo tanto, lanzar una excepción a través del código marco de Cocoa es peligroso y probablemente causará errores extraños, difíciles de diagnosticar y catastróficos (piense en la posible pérdida de datos) en su aplicación.
En lugar de usar excepciones, el código Cocoa usa NSError para señalar condiciones de error que son recuperables dentro de la aplicación. Las excepciones se utilizan para señalar las condiciones de las que su aplicación no puede recuperarse. Por lo tanto, un componente de la interfaz de usuario que solicita una posición fuera de límites en una matriz modelo podría señalarse con un error (que se presenta al usuario con una razón por la que no se pudo completar su solicitud) al intentar acceder a una posición fuera de límites dada El índice que usted considera que debería ser válido señala una condición excepcional en la que su aplicación se encuentra en un estado inconsistente y probablemente debería morir lo antes posible antes de que pueda hacer más daño.
NSParameterAssert , por ejemplo, señales con una NSException cuando falla una aserción.
Entonces, ¿cuándo deberías usar excepciones o @try/@catch ? Si está utilizando una biblioteca de C / C ++ que hace uso de excepciones, debe capturar esas excepciones antes de que puedan ser rechazadas a través del código Cocoa. De manera similar, si se toma en serio la consistencia del estado dentro de su aplicación, debe presentar una excepción tan pronto como detecte que su estado es inconsistente (e irrecuperable).
Disculpas si esta pregunta ya ha sido respondida en otro lugar, pero no pude encontrar ninguna respuesta decisiva al buscarla:
Me pregunto cuándo se van a utilizar los bloques try-catch en las aplicaciones de iPhone de object-c. La "Introducción al lenguaje de programación Objective-C" de Apple establece que las excepciones requieren muchos recursos y que no se deben "usar excepciones para el control de flujo general, o simplemente para indicar errores". De leer algunas preguntas relacionadas aquí, también deduzco que las personas no suelen utilizar este método en la práctica.
Entonces, supongo que la pregunta es: ¿cuáles son las situaciones en las que es apropiado usar los bloques try-catch cuando se desarrolla para iPhone / Objective-C y cuándo no se deben usar absolutamente?
Por ejemplo, podría usarlos para capturar más allá de los límites y otras excepciones al trabajar con objetos en matrices. Tengo un método que realiza pocas tareas con objetos que se transmiten en una serie de matrices. El método devuelve nil si se ha producido un error y un bloque try-catch podría ayudarme a detectar excepciones. Sin embargo, podría, por supuesto, simplemente escribir pocas pruebas if aquí y allá para garantizar que, por ejemplo, nunca intente acceder a un índice más allá de los límites de una matriz. ¿Qué haría usted en esta situación?
¡Muchas gracias!
Solo es apropiado usar @ try / @ catch para tratar los errores irrecuperables. Nunca es apropiado usar @ throw / @ try / @ catch para realizar operaciones de control-flujo.
En particular, no sería apropiado utilizarlo para detectar excepciones fuera de los límites a menos que su objetivo sea detectarlos e informar de alguna manera el error, luego, por lo general, bloquearse o, como mínimo, advertir al usuario que su aplicación está en un estado inconsistente y puede perder datos.
El comportamiento de cualquier excepción lanzada a través del código del marco del sistema no está definido.
Su if-test para hacer la comprobación de límites es una solución mucho más apropiada.