5

次の式は、明らかなようにJavaで有効です。

int a = -0;
int b = +0;

以下もそうです。

Integer c = new Integer(-0);
int d = Integer.parseInt("-0");
BigDecimal e = new BigDecimal("-0");

ただし、次のステートメントは無効です。

Integer f = new Integer("+0");   //Leading + sign.
int g=Integer.parseInt("+0");    //Leading + sign.

それらの両方がをスローしNumberFormatExceptionます。

ただし、次のステートメントはBigDecimal、例外がスローされることなくコンパイルおよび実行されます。

BigDecimal bigDecimal = new BigDecimal("+0");  //Leading + sign.

ここで先頭+記号が有効なのはなぜですかBigDecimal。ただし、Javaで使用可能な他のデータ型には当てはまらないようです。

4

2 に答える 2

4

ドキュメントによると、マイナス記号にはマイナス記号が必要です。ただし、正の整数の場合、プラス記号は必要ありません。

public static int parseInt(String s)

文字列内の文字はすべて 10 進数でなければなりませんが、最初の文字は負の値を示す ASCII マイナス記号「-」(「\u002D」) にすることができます。結果の整数値が返されます。これは、引数と基数 10 が parseInt(java.lang.String, int) メソッドの引数として指定された場合とまったく同じです。

次に、コンストラクターの場合:

public Integer(String s)

文字列は、基数 10の parseInt メソッドで使用される方法とまったく同じ方法でint 値に変換されます。

于 2012-10-22T02:23:59.170 に答える
3

本当の答えは、との間の一貫性のない動作が、どちらか一方の設計の誤りの結果である可能性が最も高いです。残念ながら、関連するクラスが公開されたときに間違いが「焼き付けられ」、Sun/Oracleは次の理由でそれを修正することを望んでいませんでした。new Integer("+0")new BigDecimal("+0")

  1. それぞれの実装は、それぞれの仕様に準拠しています。
  2. 不整合は、簡単な回避策を伴う比較的小さな問題であり、
  3. これを修正すると、下位互換性と下位互換性が損なわれる可能性があります。

（そして、この説明は、@ rlay3が見つけたJavaバグ＃4296955の評価セクションによってサポートされています!!）

Java式の例を考慮から除外していることに注意してください。これは、Java式の構文とテキスト文字列の変換のコンテキストが十分に異なるため（IMO） 、それらが同じように動作することを期待するべきではないためです。\（そして同じように、文字列リーダーが遭遇した文字に対して特別なことをすることを期待するべきではありません...）

アップデート

@ADTCは、Java 7で実際にこれを変更しInteger.parseInt、先頭の記号を受け入れるようになったことを確認しました。+

この拡張機能に対応するJavaのバグは＃5017980です。（リンクされたバグを見ると、最初のバグは、変更がOpenJDK6にバックポートされていることを示しているようです。）

ただし、OracleはJava 7の互換性/アップグレードドキュメントでこの変更について言及していません...互換性の懸念のためにSunが以前に変更を拒否したことを考えると、これは奇妙なことです!!

これはすべてかなり独特です...

于 2012-10-22T02:56:21.990 に答える