1

ユーザーがアプリケーションを使用しているときに例外が発生した場合に備えて、どこで例外が発生したかを特定できるようにしたいと考えています。printStackTrace() メソッドと同様のことをしたいと思います。（つまり、これはデバッグモードではなく、ビルドモード中です）

現在、すべてのクラスのほぼすべてのメソッドを try-catch ステートメント内に配置しました (各メソッドには、すべての命令を含む try-catch ステートメントがあります)。この時点で、「ツリー」またはスタックを表示できます。例外が発生した場合のメソッド。しかし、メソッド内のどこで例外が発生したかをより正確に示すために、何かの行番号を特定する方法はありますか? printStackTrace() を使用したときに表示されるものと同様です。

私は例外処理にあまり慣れていません。これを行うためのベストプラクティスは何ですか?

編集

そしてもう1つ。ビルド モードで printStackTrace() を使用すると、Logcat が使用できないため、コンテンツはどこに表示されますか? その情報を取得して何かできるでしょうか? または さらに良いことに、ビルドモード中に getStackTrace() を使用して、そこにあるものを文字列に変換し、どこかに出力できますか?

4

1 に答える 1

3

コードで処理されず、リリース モードでアプリをクラッシュさせるすべての例外は、Android 開発者コンソールのアプリの近くに表示されます。

これを機能させるには、難読化されたスタック トレースを再トレースする必要があります。

例外処理について : たとえば、これを読むことをお勧めします。すべてのコードを try/catch ブロックで囲むと、例外処理に関して間違いを犯しています。

例外処理はそれよりも微妙であり、多くの場合、設計上の考慮事項 (例外をローカルで処理するか、呼び出し元にスローするか) の影響を受けます。

要約すると、アプリのコアでは、メソッド シグネチャの throws 句を使用して、例外を処理せずにスローするか、スローするようにします。UI に近い上位レイヤーでは、例外を try/catch で処理し、エラーが発生した場合は、アプリが安定した状態であることを確認し、ユーザーに役立つメッセージを表示します。

詳細（ただし、それほど多くはありません）：

  • データベース層: 例外をスローします。それらをキャッチしてログに記録することはできますが、スローまたは再スローして、呼び出し元に何か問題が発生したことを伝えます。
  • ビジネス層: それらをキャッチし、ビジネス/ドメイン モデルが安定した状態にあり、エラーから回復することを確認し、呼び出し元にスローします。
  • UI レイヤー: 例外をキャッチし、ユーザーにいくつかのメッセージを表示します。
于 2012-04-26T19:39:28.603 に答える