iOS: excepciones de subprocesss de background que no se bloquean

No he encontrado documentation que sea coherente con mi experiencia.

Lo que quiero es una buena forma de manejar Uncaught-Exceptions en un hilo de background. Esta "manera" debería dejar que la aplicación se bloquee, pero realice algunas operaciones básicas antes de estrellarse (p. Ej., Guardar un valor en UserDefaults para que pueda ser examinado en el próximo inicio, más logging).

En el hilo principal, acabo de configurar un UncaughtExceptionHanlder y esto funciona bien. Sin embargo, en un subprocess de background, ejecutado como un NSOperation en un NSOperationQueue, se produce cualquier exception pero no sale de la aplicación: Crashing . La aplicación continúa ejecutándose en un estado dañado.

Sin embargo, la Guía de progtwigción de Threading dice:

Configuración de un controller de excepciones Si su aplicación detecta y maneja excepciones, su código de hilos debe estar preparado para detectar cualquier exception que pueda popup. Aunque es mejor manejar las excepciones en el punto en que pueden ocurrir, la falla en detectar una exception lanzada en un subprocess hace que su aplicación salga. Instalar un try / catch final en su rutina de input de hilo le permite capturar cualquier exception desconocida y proporcionar una respuesta adecuada.

Un método que funciona (a continuación) está incrustando el método thread-calling con try / catch y, en el caso de una exception, registrando y luego llamando abort (). Pero esta no puede ser la mejor manera de hacerlo. Me gustaría enviar la exception al hilo principal y que sea manejada por el manejador de exception no detectada. ¿Alguien ha hecho esto?

- (void)threadMethod { @try { NSArray* aTest = [NSArray array]; [aTest objectAtIndex:10]; } @catch (NSException* e) { // Save to state to User Defaults. // Log any needed info. abort(); } @finally { } } 

FYI: Me estoy ejecutando en iOS6, con XCode 4.5 SDK.

  1. Las NSOperationQueue ejecutadas por NSOperationQueue están siendo administradas por libdispatch , lo que atrapa las excepciones y las llamadas terminate , saliendo de la aplicación. Si estás viendo un comportamiento diferente, ya estás haciendo algo mal.
  2. Guardar datos en NSUserDefaults después de una exception es una proposition dudosa; porque el cocoa solo trata las excepciones como error del progtwigdor, no hace ningún bash de dejarse en un estado utilizable una vez que uno ha sido lanzado. En resumen, debería tratarlo de la misma manera que lo haría con un locking "real", como si solo estuvieran disponibles las API de security de señal asíncrona. Todo lo que Objective-C sale automáticamente en este sentido.
  3. Su pregunta sugiere que está intentando hacer informes de fallas. Recomendaría una solución de informes de fallos para este fin, como PLCrashReporter . También hay una serie de services de análisis y distribución que integran los informes de fallos , incluidos HockeyApp , Crashlytics , TestFlight y QuincyKit . Hay otros también, y cuál es apropiado para usted depende de sus necesidades. Todos ellos se encargarán de todos los problemas complicados relacionados con el event handling fallas y excepciones de forma segura y de save los datos para luego sin tener que preocuparse por nada de eso.

Por lo que estás haciendo, creo que necesitarás un código en tu hilo principal que verifique las cosas que suceden en tu segundo hilo. Dado que no puede ponerse en contacto con el hilo principal y disparar un evento desde el subprocess de background, lo más probable es que esté atrapado escribiendo algo en su subprocess principal que comtesting de vez en cuando. Dicho esto, probablemente podría trabajar con NSNotificationCenter y hacer que el hilo principal tenga un evento activado cuando se lanza la exception desde el hilo de background. Buena suerte.