¿El uso de NSLocking siempre debe estar en @ try/@ finalmente?

Question

Dado un objeto NSLocking Cacao (como un NSLock) y algo de código no trivial para ser ejecutado mientras se mantiene el bloqueo:

Para garantizar un bloqueo está siempre puesto en libertad, siempre se debe utilizar la siguiente expresión idiomática?

NSLock *mutex = // get lock from somewhere 
@try { 
    [mutex lock]; 
    // do non-trivial stuff 
} 
@finally { 
    [mutex unlock]; 
} 

Esto parece prudente (y común en Java), pero no he visto ningún código Cacao hacer esto.

¿Se debe usar este modismo? ¿Por qué o por qué no?

Answer 1

Para asegurarse de que siempre se suelta un bloqueo, ¿se debe usar siempre el siguiente modismo?

Sí, donde se requiere la corrección del programa después de ese alcance ('cosas no triviales'), y suponiendo que su programa puede recuperarse adecuadamente de las excepciones que encuentra.

¿Se debe usar este idioma? ¿Por qué o por qué no?

Si se puede recuperar, entonces sí, es necesario desbloquear para continuar la ejecución normalmente. De lo contrario, su programa se ejecutará en un estado no válido.

• Ejemplo 1: Cuando se destruye la cerradura (durante dealloc), el intento de destruir fallará, ya que todavía está bloqueado. Si la implementación continúa destruyendo el bloqueo o ignora el error no está definido (lo haría Supongo que persistiría, lo que significa que nunca saldría de dealloc).

• Ejemplo 2: Cuando está bloqueado de otro hilo (o el mismo hilo, si no es reentrante), nunca se obtendrá el bloqueo y, como resultado, se producirá otro error, interbloqueo o excepción. Una implementación también podría (eventualmente) proceder sin bloqueo adquirido. Todo lo que está garantizado es iniciar sesión cuando/si se detecta un error.

pthread_mutex ES y las implementaciones que dependen de ellos no se comporte con mucha gracia si tiene un desequilibrio de bloqueo; esto siempre recae en un error del programador.

El bloqueo correcto y defensivo en objc puro yc no es muy bonito. La expresión de Java es correcta e igualmente aplicable a las API de la Fundación. La razón por la que no se ve tanto puede sea porque las excepciones son un mecanismo de manejo de errores menos popular/usado dentro de las API Cocoa y los programas que dependen de ellos (en comparación con Java). ver también la nota de Bavarious' en los comentarios

Answer 2

Nº

excepciones sólo se utilizan para los errores de programación en Cocoa. No se usan para situaciones donde se espera que el programa se recupere.