3

現在の動作:

  • 行にブレークポイントを置きますcase Twice(n) ...。
  • 「ステップイン」すると、コントロールはx match {行に移動します
  • 「ステップイン」すると、コントロールはdef TwiceTest = {行に移動します
  • さらに「ステップイン」すると、コントロールはif (z % 2 == 0)...行に移動します。

予想される行動：

  • 行にブレークポイントを置きますcase Twice(n) ...。
  • 「ステップイン」すると、コントロールはif (z % 2 == 0)...行に移動します。

コードスニペット

object testobj extends App {
  def TwiceTest = {
    val x = Twice(21)
    x match {
      case Twice(n) => Console.println(n)
    } // prints 21
  }

  TwiceTest

}

object Twice {
  def apply(x: Int): Int = x * 2
  def unapply(z: Int): Option[Int] = {
    if (z % 2 == 0) Some(z / 2) else None
  }
}

現在の動作は、多数のネストされたエクストラクタを含む scala プログラムをデバッグしているときにイライラします。これを新しい Scala デバッガーと Java デバッガーで試しましたが、結果は同じでした。

Step Filteringこの場合も役に立ちません。

回避策として、unapplyメソッドにブレークポイントを設定しresume、最初のブレークポイントから実行しています。誰かが私にもっときれいな方法を提案してくれませんか。

編集 1 Scala-IDE を使用しています (最新のナイトリー ビルド。 2.1.0.nightly-2_09-201208250315-529cd70 )

Eclipse バージョン: Indigo Service Release 2 ビルド ID: 20120216-1857

OS：Windows7（64ビット）

4

1 に答える 1

0

バイトコードの行番号情報が間違っています。これは IDE の問題ではなく、Scala コンパイラの問題です。パターン マッチングがコンパイルされると、合成コードが間違った位置情報を取得することがあります。

Scala 2.9.2 を使用していると仮定します。Scala の次のバージョン (2.10.0) では、パターン マッチャーが大幅に改善されているので、試してみるとよいでしょう。

于 2012-08-27T11:57:28.503 に答える