1

現時点では、Playframework2 を使用しながら Web サイトを開発しています。私はプログラミングの初心者です。例外に関する本を何冊か読んだことがありますが、現実の世界では、例外処理は本当に奇妙です。

正直に言うと、どの例外がスローされるかはあまり気にしません。すべての例外を同じ方法で処理します。 return badrequest();. ロギングには例外のみを使用します。

try{
...
}
catch(Exeption e){
//log
return badrequest();
}

しかし、これは非常に多くの定型文であり、すべてのメソッドが同じ例外をスローするため、書くのは本当に面倒です。

あなたが私に与えることができるヒント、ヒント、またはリソースはありますか?

編集：

例は、私の「グローバル」構成ファイルです。この問題に対してシングルトンを作成できると考えるたびに、データベースに接続する必要があるためです。

private Datastore connect() throws UnknownHostException, MongoException,
            DbAuthException {

        Mongo m = new Mongo(dbUrl, dbPort);
        Datastore ds = new Morphia().createDatastore(m, dbName);
        boolean con = ds.getDB().authenticate(username, password.toCharArray());
        if (!con)
            throw new DbAuthException();
        return ds;
    }

これにより、データベースに接続するたびに試行とキャッチが行われます。私の問題は、それらを慎重に扱うことができないと思うことです.

コード例:

public static Result addComment(String title) {
        try {

            Datastore ds = DatabaseConnect.getInstance().getDatastore();
            Form<Comment> filledForm = commentForm.bindFromRequest();
            Comment userComment = filledForm.get();
            userComment.setUsername(Util.getUsernameFromSession(ctx()));
            User.increasePointsBy(ctx(), 1);
            UserGuides.addComment(title, userComment);
        } catch (Exception e) {
            return badRequest();
        }
        return redirect(routes.Guides.blank());
    }

この場合、同じ try と catch を何度も何度も書くのが面倒でした。これは重複したコードです。

例外処理を伴う大きなアプリケーションを設計する方法を説明した本があるかもしれません。

4

2 に答える 2

4

メソッドを呼び出すとき、必ずしもその場で例外をキャッチする必要はありません。呼び出し元にそれらを処理させることができます (チェック済み例外の場合は throws 節を宣言します)。実際、追加の作業なしでそれらを呼び出し元に渡す機能は、例外の際立った特徴です。

私のチームは、次のコーディング標準を採用しています。障害から回復したい場合は、まれにチェック例外をスローし、それ以外の場合は非チェック例外をスローします。コール スタックの非常に高い位置にあり、すべてのリクエストがそれを通過するメソッドには、未チェックの例外に対する catch ブロックが 1 つしかありません (たとえば、 内ServletFilter)。この catch ブロックは例外をログに記録し、ユーザーを「申し訳ありませんが、これは発生すべきではありませんでした」ページに転送します。

于 2012-08-16T20:21:46.717 に答える
3

コードを調べて、これらすべての例外をスローしている理由を調べましたか? 例外には理由があります。何かがうまくいかなかったことを伝えるためです。「ボイラープレート」コードを書きすぎてtry-catchいて、1,000 行のアプリケーションを使用していない場合は、リファクタリングする必要があります。

try-catch複雑なブロックを持っているといらいらすることがあり、非常に単調でボイラープレートになる可能性があります ( Marc Gravell は、彼が通常使用しているとさえ言ってtry-finallyいます)。これらの例外を処理または回避します。

akf が言及しているように、例外を無視することもデバッグに危険を及ぼす可能性があります。壊滅的な問題が発生した場所を追跡するのは、その原因となる例外を見逃していると、追跡が難しくなります。

于 2012-08-16T20:09:28.333 に答える