0

Android 3.1以降のアプリケーションを開発していますが、この質問は特定の環境に固有のものではありません。

アクティビティ（プレゼンテーション）、モデル（データベーステーブルを表すオブジェクト）、データ（SQLiteデータベースにアクセスするためのクラス）の3つのレイヤーがあります。

私のデータベースメソッドはすべて次のようなものです。

public void insertUserAnswers(ArrayList<UserAnswer> answers)
{
    try
    {
        if ((db == null) || (!db.isOpen()))
            this.open();
    }
    catch (Exception e) {
        e.printStackTrace();
    }
    finally
    {
        this.close();
    }
}

ご覧のとおり、私はすべての例外をキャッチし、それについて誰にも通知しません。なぜなら（そしてこれが私の問題です）私はそれを行う方法がわからないからです。

SQLコマンドでエラーが発生したことを通知するにはどうすればよいですか？それを行うためのパターンはありますか？

例外をキャッシュするかどうかを示す値を返すことができると思います。

4

4 に答える 4

1

まず、そのようなすべての例外をキャッチしないでください。何が問題なのかを知り、ユーザーに正確に何が問題なのかを通知することが難しくなります。代わりに、次のようにします。

try {
    operationThatThrowsMultipleExceptions();
}
catch (ExceptionTypeOne e){
    // do something here
}
catch (ExceptionTypeTwo e){
    // do something here
}
catch (Exception e){
    // do something here
}

Exception何も見逃していないことを確認するために、すべてをキャプチャするタイプのもののように、最後にキャプチャしていることがわかります。

モデルに関して言えば、私が行う方法は、アクティビティが処理できるように、すべてのデータ レイヤー オブジェクトがプレゼンテーション レイヤー (アクティビティ) まで例外をスローするようにすることです。プレゼンテーション レイヤーでは、ユーザーにエラーを表示する方法を選択できます。通常は、わかりやすく有益なエラー メッセージで表示されます。ただし、常にそうであるとは限りません。たとえば、モデルにデータを入力していて、DB からのリターンがないためにヌル ポインターにヒットした場合、データ レイヤーで問題をキャッチし、モデルにデータを入力しないでください。次に、プレゼンテーション層がモデルを提示するとき、そこには何もありません。それが、プレゼンテーション層がそれをユーザーに伝える方法を決定できるポイントです。

要約すると、本当に必要でない限り、データ層で例外をキャッチしないでください。

于 2012-05-09T14:19:32.867 に答える
0

SQLiteOpenHelperデータベースを開くために (1 回またはまれに) を参照することをお勧めします。ContentProvider複数のプロセスまたはアプリがデータにアクセスできるようにする場合は、 と組み合わせます。

次に、コードが (SQLite レベルなどで) エラーを生成しないことを確認し、何かを忘れた場合は単にアプリをクラッシュさせます。これは、何か間違ったことをしたことを知る最も安全な方法であり、Play / Market を介してエラーを報告することもできます。

例外のキャッチは、場合によってはエラーが発生すると予想されるコード (ファイル I/O など) があり、それらの処理方法を知っている場合にのみ有効です。

すべてをキャッチすると、単にエラーが隠され、検出が困難になります (ユーザーは、ログ メッセージなどを常に監視する必要があります)。アプリがクラッシュしないが、実行にデータベースが必要なために使用できない場合、アプリがクラッシュするだけでなく、ユーザーを混乱させる可能性があります。

メッセージを単純に logcat に出力するには、次を使用します。

catch (Exception e) {
    // either 
    Log.w("TAG", e);
    // or
    Log.e("TAG", "some message", e);
}

これにより、使用する代わりに選択できるタグ/ログレベルでメッセージが出力されますW/System.err

于 2012-05-09T14:23:43.223 に答える
0

一般的に言えば、エラーに対処する場合、または他のオブジェクトがエラーに対処できるようにする場合 (グレースフル デグラデーションなど) は、適切な戻り値を返すように修正されているようです。このinsertUserAnswersメソッドは、次に例を示す数値を返すことができます。

0: "Success"
1: "IO error (file system not accessible or so)"
2: "SQL error (invalid insert query, invalid arguments, ...)"

Exceptionこれにより、何が問題なのかを判断するために、ベースよりも具体的な例外をキャッチする必要が生じる可能性があります。

また、ユーザーとして、エラーに関する技術的なことは気にしません。エラーがあったかどうかに興味があるかどうかさえわかりません。したがって、エラー ダイアログを表示することは、必ずしも「エラーに対処する」ことではありません。それが唯一の目的である場合 (エラー ダイアログを表示する場合) は、戻り値を気にせず、エラー通知を完全にスキップすることをお勧めします。

常に何らかの方法でエラーをログに記録する必要があります (Log.e("MyTag", "My log message")必要に応じて、独自のログ インフラストラクチャによって)。

于 2012-05-09T14:16:35.863 に答える
0

そうですね、申し訳ありませんが、あなたの質問を適切に読まなかったので、回答を変更します。

これは、予想している例外の種類に大きく依存します。すべての例外を無効にしていることがわかりますが、それを特定の例外に絞り込むことができるはずです。呼び出し元に例外を処理させてから、トーストなどを表示できます。例外が回復可能な場合、ユーザーを支援します。

于 2012-05-09T14:02:52.953 に答える