2013-03-20 8 views
10

C'è un modo per impedire a uno EXC_BAD_ACCESS di bloccare un'app, come con @[email protected] è possibile gestire un'eccezione con garbo.Come prevenire EXC_BAD_ACCESS dall'arresto anomalo di un'app?

Aggiornamento:

Il codice si blocca quando tenta di dereference un puntatore non valido. Questa è una libreria di terze parti e si interfaccia con l'hardware esterno, quindi non posso eseguire il debug localmente. Sto cercando di impedirne l'arresto anomalo e di inviare i dati a una console di debug sulla mia app.

risposta

12

In ObjC, try/catch non gestisce eccezioni particolarmente con grazia. Perderai ancora memoria e lascerai il sistema in uno stato indefinito. Con rare eccezioni, ci si aspetta che si stia semplicemente prendendo in modo da poter registrare alcune cose prima di bloccarsi. E in generale, non dovresti usare @catch ovunque ma al livello più alto del tuo programma per questo scopo. Ci sono alcune situazioni straordinarie in cui l'uso limitato di eccezioni può essere appropriato, ma sono rari in ObjC. Vedere lo Exception Programming Guide per ulteriori informazioni. Vedi in particolare il seguente da ObjC ARC documentation:

La convenzione di cacao standard è che le eccezioni segnalano l'errore del programmatore e non sono da recuperare. Rendere le eccezioni di codice-sicure per impostazione predefinita imporrebbe gravi runtime e dimensioni del codice delle penalità sul codice che in genere non si preoccupa delle eccezioni di sicurezza. Di conseguenza, il codice generato da ARC perde per impostazione predefinita sulle eccezioni, il che va bene se il processo verrà immediatamente terminato comunque. I programmi che si preoccupano del ripristino da eccezioni dovrebbero abilitare l'opzione [-fobjc-arc-exceptions, che impone la velocità e le penalità della memoria sul programma].

Lo stesso vale per EXC_BAD_ACCESS. Puoi prenderlo con un gestore di segnale allo scopo di registrare alcune informazioni e poi terminare il crash. Per un buon strumento per farlo vedi PLCrashReporter. È molto difficile scrivere correttamente un gestore di questo tipo, quindi consiglio vivamente di utilizzare un framework esistente. Si può facilmente entrare in deadlock che scaricano la batteria dell'utente se si cattura EXC_BAD_ACCESS in modo errato.

7

È possibile riscrivere il codice per non avere questi errori. Cerca di non fare riferimento a puntatori nulli e di mantenere riferimenti a qualsiasi oggetto a cui desideri avere accesso.

+1

Questo! Alcuni errori, tu davvero non vuoi provare e continuare :-) – paxdiablo

+1

+1 Con solo un po 'di cura e difesa nella programmazione, consistenza rigorosa (in particolare usando gli accessor piuttosto che i ivars), e usando "trattare gli avvertimenti come errori", I scopri che questo tipo di incidenti diventa molto raro. –

+1

Grazie per il consiglio ma non è il mio codice.È un codice di libreria di terze parti e sto cercando di eseguire il debug in remoto. Non riesco a eseguire il debug con Xcode poiché si interfaccia con l'hardware esterno. Ho fatto questa domanda per un motivo. – Boon

11

È possibile ottenere EXC_BAD_ACCESS spesso perché si è inviato un messaggio a un oggetto rilasciato. Quindi è possibile esaminare il NSZombie. Cos'è un NSZombie? È possibile vedere: this. Otterrà lo EXC_BAD_ACCESS a causa di un messaggio inviato all'oggetto rilasciato.

È possibile impostare NSZombie in questo modo: Controllare il Enable Zombie Objects enter image description here

E si può anche ottenere EXC_BAD_ACCESS a causa degli avvisi di memoria livello è troppo alto, o la memoria è troppo alto, in modo che l'Apple chiudi l'app giù. Questo EXC_BAD_ACCESS è troppo difficile da prevenire. Penso che l'unico modo sia di gestire la memoria più bassa che puoi, a volte puoi vedere il log dove è receive memory warning, quando il livello è alto, potrebbe essere EXC_BAD_ACCESS