例外を適切に処理できるEXC_BAD_ACCESS
ように、アプリのクラッシュを防ぐ方法はありますか。@try..@catch
アップデート:
無効なポインターを逆参照しようとすると、コードがクラッシュします。これはサードパーティのライブラリであり、外部ハードウェアとのインターフェイスであるため、ローカルでデバッグできません。クラッシュを防ぎ、アプリのデバッグ コンソールにデータを出力しようとしています。
例外を適切に処理できるEXC_BAD_ACCESS
ように、アプリのクラッシュを防ぐ方法はありますか。@try..@catch
アップデート:
無効なポインターを逆参照しようとすると、コードがクラッシュします。これはサードパーティのライブラリであり、外部ハードウェアとのインターフェイスであるため、ローカルでデバッグできません。クラッシュを防ぎ、アプリのデバッグ コンソールにデータを出力しようとしています。
ObjCでは、try/catchは例外を特に適切に処理しません。それでもメモリリークが発生し、システムは未定義の状態のままになります。まれな例外を除いて、クラッシュする前にいくつかのことをログに記録できるように、単にキャッチしていることが期待されます。そして一般的に、あなたは@catch
この目的のためにあなたのプログラムのトップレベル以外のどこでも使うべきではありません。例外の限定的な使用が適切な場合もありますが、ObjCではまれです。詳細については、 『例外プログラミングガイド』を参照してください。特に、ObjCARCのドキュメントから次を参照してください。
標準のCocoaの規則では、例外はプログラマーエラーを通知し、回復することを目的としていません。コードの例外をデフォルトで安全にすると、通常は例外の安全性を実際に気にしないコードに、実行時間とコードサイズに厳しいペナルティが課せられます。したがって、ARCで生成されたコードは、デフォルトで例外でリークします。これは、プロセスがとにかくすぐに終了する場合は問題ありません。例外からの回復を気にするプログラムは、オプション[-fobjc-arc-exceptions、プログラムに速度とメモリのペナルティを課す]を有効にする必要があります。
同じことが。にも当てはまりますEXC_BAD_ACCESS
。いくつかの情報を記録してクラッシュを終了する目的で、シグナルハンドラーでそれをキャッチできます。これを行うための優れたツールについては、PLCrashReporterを参照してください。このようなハンドラーを正しく作成することは非常に難しいため、既存のフレームワークを使用することを強くお勧めします。EXC_BAD_ACCESS
誤ってキャッチすると、ユーザーのバッテリーを消耗させるデッドロックに簡単に陥る可能性があります。
EXC_BAD_ACCESS
リリースされたオブジェクトにメッセージを送信したため、頻繁に取得されます。次に、を調べることができますNSZombie
。NSゾンビとは?あなたが見ることができます:これ。EXC_BAD_ACCESS
解放されたオブジェクトにメッセージを送信したため、それをキャッチし
ます。
次のように NSZombie を設定できます。Enable Zombie Objects
またEXC_BAD_ACCESS
、 memory warnings level is too high 、または memory is too high が原因で、Apple がアプリをシャットダウンすることもあります。これ EXC_BAD_ACCESS
は防ぐのが難しすぎます。唯一の方法は、メモリをできるだけ低く管理することだと思います。ログがどこにあるかを見ることができる場合があります。receive memory warning
レベルが高い場合は、EXC_BAD_ACCESS
これらのエラーが発生しないようにコードを書き直すことができます。null ポインターを参照しないようにして、アクセスしたいオブジェクトへの参照を保持してください。