10

私は Java での自動ボクシングの大ファンです。これにより、見苦しいボイラー プレート コードが大幅に節約されます。ただし、 Number オブジェクトが null である可能性がある状況では、自動ボックス化解除が混乱を招くことがわかりました。javac警告でコードベースで自動アンボックス化が発生している場所を検出する方法はありますか? ボックス化解除のみの発生を検出する他のソリューション (FindBugs や Eclipse 固有のコンパイラ警告など) が見つからないため、高く評価されます。

明確にするために、ボックス化時に警告を生成したくありません-ボックス化解除のみ。

混乱を招く NullPointerExceptions を引き起こす可能性のあるコードの簡単な例を次に示します。 

class Test {
    private Integer value;

    public int getValue() {
        return value;
    }
}
4

4 に答える 4

5

うん。エクリプスでは:

設定 -> Java -> コンパイラ -> エラー/警告 -> 潜在的なプログラミングの問題 -> ボックス化とボックス化解除の変換

于 2010-01-09T13:31:02.500 に答える
2

残念ながらありません。これは、自動アンボックス番号の問題の 1 つです。あなたはできる

  • 次のようなデフォルト値に初期化します。private Integer value = 0
  • null をチェックするreturn value != null ? value : 0

個人的には最初の方法が好きです。一般に、null 番号を使用する必要があるケースはあまりないと思います。

また、値を格納するために大きな整数を使用するのはなぜですか。少しだけ int を返す場合は、そのように保存してみませんか?

于 2010-01-09T14:24:24.513 に答える
1

これが警告のケースになるとは思えません。これは、自動ボクシングの癖の1つです。

Joshua Blochは、彼の著書「EffectiveJava」でこれに取り組んでいます。基本的に、コンパイラーは、期待されている以上のことを実行しようとしています。言い換えると、このタイプの問題はより一般的に使用法に関連しており、その結果、エラーは意味的に言えば単にそこにないため、「エラーを見つける」ことは困難です。

于 2010-01-09T16:37:24.663 に答える
1

Eclipse では、構文カラーのボックス化とボックス化解除の操作が可能です (ただし、どちらか一方は不可)。私はそれらを真っ赤に設定しています: どちらかが起こった場合、それは私がパラメータと引数の一致にずさんだったことを意味します.

于 2010-01-09T14:51:04.300 に答える