2012-10-02 15 views
8

leí la recomendación de Apple en exception uso y NSError uso:Pros y contras del uso de excepción en IOS/ObjectiveC

Además, he leído varias preguntas de desbordamiento de pila similares que tratan sobre si se debe utilizar o no la excepción.

Exception Handeling in iOS

Using exceptions in Objective-C

Objective-C Exceptions

Estoy tratando de averiguar los pros y los contras de excepción el uso como una notificación de error/método de manejo en IOS (Francamente, no soy satisfecho con la sentencia de Apple (dice qué hacer, pero no dice por qué deberíamos hacerlo):

Debe reservar el uso de excepciones para programación o errores de tiempo de ejecución inesperados, como acceso a colecciones fuera de límites, intentan mutar objetos inmutables, enviar un mensaje no válido y perdiendo la conexión con el servidor de ventanas. Por lo general, se ocupa de este tipo de errores con excepciones cuando se crea una aplicación en lugar de hacerlo en tiempo de ejecución.

pros de uso Excepción:

  • No requiere modificar todo el código intermedio entre código de generación de error y el código de control de errores

  • No contamina argumentos y valores de retorno para métodos

Contras:

  • Para todos los códigos de memoria administrados manualmente, tendremos que tener un cuidado extra (necesitaremos envolverlo en objetos liberados automáticamente para garantizar que se liberen los recursos).

  • Tenemos que tener cuidado con el borde entre nuestro código y el marco. Si nuestras excepciones dejan nuestro código, podríamos tener problemas (porque los marcos pueden administrar memoria manualmente)

¿Echo de menos algo? ¿Hay contras/pros adicionales?

Parece que las excepciones deberían estar bien para el código tipo biblioteca (cuando tenemos una cantidad bastante grande de código empaquetado, que no se comunica mucho con sistemas/frameworks externos. Y parece que las excepciones son difíciles de usar para . el código que interactúa activamente con otros marcos

¿su experiencia de probar esta teoría

agradezco cualquier información adicional sobre este tema

+1

Realmente no veo los contras. De todos modos, quieres hacer estas dos cosas, ¿verdad? – Sulthan

+0

Diría que primero no es una estafa. Tienes que hacerlo de todos modos. En segundo lugar podría ser una especie de dolor (como entiendo que ObjectiveC (Java) no proporciona una buena manera de que el desarrollo sepa que algún método puede arrojar. Por lo tanto, es fácil agregar un método en el código de borde y olvidarlo para captar la excepción que podría arrojarse con este código. –

+0

El problema, sin embargo, es que el límite entre el código y el código del sistema suele ser extremadamente complejo. Si usa las clases de la colección Foundation, cada uso de esas colecciones es un borde, por ejemplo, – bbum

Respuesta

13

tl;?. Excepciones dr deben utilizarse para fatales/no recuperable/error (s) del programador solamente.Intentar utilizarlos a la Java u otras excepciones son entornos recuperables dará como resultado un código que es más frágil, más difícil de mantener y difícil de refactorizar, al tiempo que limita su capacidad para aprovechar los marcos del sistema.


aire acondicionado: Si utiliza excepciones para el control de flujo y/o errores recuperables en su código, el código será, por diseño, diferente de los patrones de diseño de Apple.

Resultado final?

• No se pueden utilizar las API de Apple en absoluto en el código a menos que la frontera entre el código y Apple de siempre aísla el comportamiento excepción

• Cada vez que su refactor, tendrás que refactorizar una masa de código de manejo de excepciones

• Muchas cosas que deberían ser triviales serán muy complejas; por ejemplo, no podrá colocar sus objetos en una colección enumerable y enumerarlos sin esa enumeración --bloque, para bucle, lo que sea ... - que también tenga procesamiento de excepción en los límites.

considerar:

NSArray *a = @[yourExceptionfulInstance, yourExceptionfulInstance, yourExceptionfulInstance]; 

@try { 
    for(id k in a) { [k doSomething]; } 
} @catch(...) { 
} 

Si doSomething podría plantear, por cualquier razón, lo anterior es violación de los patrones de diseño documentados del marco porque estará lanzando una excepción través marcos en el marco de Apple (s).

Esa es una gran estafa. Lo suficientemente grande como para no poder imaginar un conjunto de profesionales que lo superen.

+0

Buen punto. Gracias. –