私のプログラムには次のコードがあり、Mavenと統合した後、コード品質チェックのためにSonarQube 5を実行しています。
ただし、Sonarはこの例外をログに記録するか、この例外を再スローするとすべきだと不満を言っています。
ここで何が欠けていますか?例外を既にログに記録していませんか?
private boolean authenticate(User user) {
boolean validUser = false;
int validUserCount = 0;
try {
DataSource dataSource = (DataSource) getServletContext().getAttribute("dataSource");
validUserCount = new MasterDao(dataSource).getValidUserCount(user);
} catch (SQLException sqle) {
LOG.error("Exception while validating user credentials for user with username: " + user.getUsername() + " and pwd:" + user.getPwd());
LOG.error(sqle.getMessage());
}
if (validUserCount == 1) {
validUser = true;
}
return validUser;
}
このようにする必要があります:
try {
DataSource dataSource = (DataSource) getServletContext().getAttribute("dataSource");
validUserCount = new MasterDao(dataSource).getValidUserCount(user);
} catch (SQLException sqle) {
LOG.error("Exception while validating user credentials for user with username: " +
user.getUsername() + " and pwd:" + user.getPwd(), sqle);
}
ソナーはもう気にしないでください
ソナーが行うように求めているのは、例外オブジェクト全体を永続化することです。次のようなものを使用できます。
try {
...
} catch (Exception e) {
logger.error("Error", e);
}
SQLExceptionを安全に無視できると思われる場合は、squid:S1166ルールの例外のリストに追加できます。
私は同じ問題に出くわしました。この時点で完全に正しいかどうかは100%わかりませんが、基本的には完全な例外を再スローまたはログに記録する必要があります。 e.getMessage()
は詳細なメッセージを提供するだけで、実行スタックのスナップショットは提供しません。
スロー可能オブジェクトには、作成時のスレッドの実行スタックのスナップショットが含まれています。エラーに関する詳細情報を提供するメッセージ文字列を含めることもできます。時間の経過とともに、スロー可能オブジェクトは、他のスロー可能オブジェクトの伝播を抑制できます。最後に、スロー可能オブジェクトには、原因を含めることもできます。このスロー可能オブジェクトを作成した別のスロー可能オブジェクトです。この原因情報の記録は、連鎖例外機能と呼ばれます。これは、原因自体に原因があるなどで、それぞれが別の例外によって引き起こされる例外の「連鎖」につながるためです。
これは、例外オブジェクト(sqle)全体がロガーに渡されるため、abarreが提供するソリューションが機能することを意味します。
それが役に立てば幸い。乾杯。