web-dev-qa-db-ja.com

良い習慣を主張するかどうか?

有効性を強制するために、関数パラメーターにAssertを使用するのは良い習慣ですか?私はSpring Frameworkのソースコードを調べていましたが、Assert.notNullを多く使用していることに気付きました。ここに例があります

   public static ParsedSql parseSqlStatement(String sql) {
    Assert.notNull(sql, "SQL must not be null");}

もう1つあります。

public NamedParameterJdbcTemplate(DataSource dataSource) {
            Assert.notNull(dataSource,
                    "The [dataSource] argument cannot be null.");
            this .classicJdbcTemplate = new JdbcTemplate(dataSource);
        }

        public NamedParameterJdbcTemplate(JdbcOperations classicJdbcTemplate) {
            Assert.notNull(classicJdbcTemplate,
                    "JdbcTemplate must not be null");
            this .classicJdbcTemplate = classicJdbcTemplate;
      }

参考までに、Assert.notNullassertステートメントではない)は、utilクラスで次のように定義されています。

public abstract class Assert { 
   public static void notNull(Object   object, String   message) {
      if (object == null) {
          throw new IllegalArgumentException  (message);
      }
   }
}
48
ken

原則として、 アサーション は他の多くの実行時チェックとそれほど違いはありません。

たとえば、Java実行時にすべての配列アクセスをバウンドチェックします。これにより、物事が少し遅くなりますか?はい。それは有益ですか?絶対に!範囲外違反が発生するとすぐに、例外がスローされ、プログラマーはバグの可能性を警告されます!配列アクセスがバインドされていない他のシステムの動作は、予測不可能です(多くの場合、悲惨な結果をもたらします!)。

アサーションは、ライブラリまたは言語サポートを使用するかどうかにかかわらず、精神的に似ています。パフォーマンスにはコストがかかりますが、絶対に価値があります。実際、アサーションは明示的であり、より高いレベルの概念を伝えるため、アサーションはさらに価値があります。

適切に使用すると、パフォーマンスコストを最小限に抑えることができます。また、クライアント(契約違反は後よりも早くキャッ​​チされる)と開発者(契約はself-enforcingおよび自己文書化)、最大化されます。

それを見る別の方法は、アサーションを「アクティブなコメント」と考えることです。コメントが有用であると主張することはありませんが、それらは受動的です。計算上は何もしません。いくつかの概念をコメントではなくアサーションとして定式化すると、それらはアクティブになります。実際には、実行時に保持する必要があります。違反がキャッチされます。


参照: アサーションを使用したプログラミングの利点

57

これらのアサートはライブラリによって提供され、組み込みのassertキーワードとは異なります。

ここには違いがあります:assertsはデフォルトでは実行されません(-eaパラメーターで有効にする必要があります)が、Assertクラスによって提供されるアサーションは無効にできません。

私の意見では(価値があるため)、これはパラメーターを検証するための方法と同じくらい良い方法です。質問のタイトルが示すように、組み込みのアサーションを使用していた場合、必要なチェックを削除することはできないという根拠に基づいて議論していました。しかし、この方法は以下の略記です:

public static ParsedSql parseSqlStatement(String sql) {
    if (sql == null)
        throw new IllegalArgumentException("SQL must not be null");
    ...
}

...これは常にパブリックメソッドで行うことをお勧めします。

組み込みスタイルのアサートは、条件が常に真である必要がある状況、またはプライベートメソッドの場合に便利です。 アサーションを紹介する言語ガイド には、基本的に私が今説明したものであるいくつかの良いガイドラインがあります。

28
Michael Myers

はい、それは良い習慣です。

Springの場合、チェックは通常XMLワイヤリングファイルから来るプロパティ設定などを検証するため、特に重要です。つまり、webappの構成を検証しています。また、Springベースの本格的な開発を行う場合、これらの検証チェックにより、愚かな構成ミスを犯した場合のデバッグ時間を節約できます。

ただし、AssertというライブラリクラスとJava assertキーワードを定義するために使用されるJavaアサーション:後者の形式のアサーションは、アプリケーションの起動時にオフにすることができ、常に発生させたい引数の検証チェックには使用しないでください。 webapp構成の健全性チェックをオフにします...そして同意します。

[〜#〜] update [〜#〜]

Java 7(以降)でJava.util.Objectsクラスは、引数がrequireNonNullであるかどうかをテストし、例外を発生させる便利なメソッド null を提供します。次のように使用します。

 SomeType t = ...
 SomeType tChecked = Objects.requireNonNull(t);

または

 SomeType tChecked = Objects.requireNonNull(t, "t should be non-null");

ただし、このメソッドはNullPointerExceptionではなくIllegalArgumentExceptionを発生させることに注意してください。

18
Stephen C

Sunのアサーションの ガイド に基づいて、パブリックメソッドの引数チェックにアサーションを使用するnotを使用する必要があります。

引数のチェックは通常、メソッドの公開仕様(または契約)の一部であり、これらの仕様はアサーションが有効か無効かに応じて従う必要があります。

6
kiwicptn

非常に大規模で不十分な設計/保守システムで、たとえば6000行の長さの方法で予測可能性を改善したい場合、社内の誰もそれらを理解していない場合、開発環境を引き起こすためにassertキーワードを使用することは有益です爆破して、バグを明らかにします。しかし、これらのアサーションを実稼働環境で実装する場合、恐ろしく考えられていた問題を修正するパッチを短絡する可能性があります。実稼働環境ではなく、開発環境で発見することで、その悪いパッチを修正したいのです。したがって、開発時にアサートをオンにし、本番環境ではオフにします。

開発時のassertキーワードのもう1つの有効な使用法は、サブミリ秒単位で実行する必要があり、予測不能またはテストされていない呼び出し元から十分に隔離されたアルゴリズムに有効性チェックを挿入することです。このような場合、本番環境で有効性チェックを保持する余裕がないかもしれませんが、開発ではまだ非常に便利です。一方、検証しているパラメーターのソースが予測不能であるか、そうなる可能性がある場合(たとえば、ユーザー入力によって部分的に決定される場合)、おそらく実稼働環境でもチェックをスキップする余裕はないでしょう。パフォーマンスヒットをビジネスのコストと見なします。 (この最後のケースでは、おそらくアサートを使用したくないでしょう。)しかし、アサートを選択して、実稼働時の妥当性チェックを削除する必要がありますonlyプロファイリングがあなたに単にオーバーヘッドを支払う余裕がないことを伝えた後。

2
nclark

はい、それは良い考えです。インターフェイスまたはクラスの縮小を強制しています。契約違反がある場合は、できるだけ早く検出する必要があります。長く待つほど、結果は予測不能になり、診断が難しくなります。

このように明示的にチェックする場合は、ログファイルで表示したときに、根本的な原因を見つけるのに役立つコンテキストを提供できる情報メッセージも提供する必要があります。

1
cletus

私はリリースされたバイナリでアサーションを保持していますが、動作が変更されています:abortは呼び出されませんが、stacktraceは収集されます。

詳細はこちら: http://blog.aplikacja.info/2011/10/assert-to-abort-or-not-to-abort-thats-the-question/

0
Dariusz Cieslak