-1

次のように、クラスがそれ自体のインスタンスを返すための静的メソッドを公開する、かなり標準的な作成パターンがあります。

public class MyClass {

    private MyClass(/*parameter list*/) {
        // internal construction
    }    

    public static MyClass GetMyClass(/*parameter list*/) {
        return new MyClass(/*parameter list*/);
    }
}

...

//this line wont break in the debugger and seemingly never gets called - why?
MyClass inst = MyClass.GetMyClass(/*parameter list*/);

ただし、inst常に null です。静的メソッドを呼び出す行で中断できません。デバッガーはそれを無視します - 何が起こっているのですか?

編集：提案をありがとう。

  • すべてのプロジェクトがクリーンアップされ、再構築されました (NetBeans で手動で)
  • 静的メソッドにブレークを追加しましたが、ヒットしません。
  • はい、上記のコードは Swing 'FrameView' のコンストラクターで (最終的に) 呼び出されていますが、これをどこから呼び出しているかは問題ではありません。
  • どこでも飲み込むことは例外ではありません

補足として、欠落しているclass宣言 (タイプミス) 以外に、なぜこれが有効な Java ではないのでしょうか? なぜこれは明らかにC# コードなのですか? 反対票よりも説明の方が役に立ちます:)

編集 II:Paramsは、パラメーターの負荷全体を示すことになっています。これが誰かを混乱させた場合は申し訳ありません。パラメーターには型宣言などがあることは明らかです。上記のコードは、完全なおよび (複雑な) ではなく、簡単な省略形として意図されていました。実際のサンプル...

4

7 に答える 7

1

これを行うことから始めます：

public class MyClass 
{
    private MyClass(/*parameter list*/) 
    {
        System.out.println("entering MyClass(...)");
        // internal construction
        System.out.println("leaving MyClass(...)");
    }    

    // Java uses lower case for method names - so get not Get
    public static MyClass getMyClass(/*parameter list*/) 
    {
        final MyClass foo;

        System.out.println("entering getMyClass(...)");

        foo = new MyClass(...);

        System.out.println("leaving getMyClass(...)");

        return (foo);
    }
}

...

MyClass inst = MyClass.getMyClass(/*parameter list*/);

デバッガーの外部でコードが呼び出されるかどうかを確認します。

例外をキャッチしている場合は、少なくとも次のことを行ってください。

catch(final WhateverException ex)
{
    // at the very least do this so you can see that the exception happens
    ex.printStackTrace();
}

Throwable、Error、Exception、RuntimeExceptionをキャッチしないようにします。実際、それを行う最善の方法は、すべてのcatchステートメントを削除してから、コンパイラーが必要であると通知したものに対してのみcatchを追加することです。

もう1つは、MyClass inst = MyClass.getMyClass（/ parameter list /）;の場所を指定しないことです。から呼び出されます。その線が決してヒットしない可能性は完全にあります。

于 2009-12-30T21:10:10.367 に答える
1

これはFrameViewのコンストラクターから呼び出しているとのことですが、そのインターフェイス/オブジェクトの実装または拡張について話していると思います。私の推論は、コンストラクターを再帰的に呼び出さないようにすることでした。

于 2009-12-30T21:10:33.937 に答える
1

に問題はありません:

MyClass inst = MyClass.GetMyClass(Params);

そのコード行の前後に何があるかによって異なります。

于 2009-12-30T20:36:08.603 に答える
1

いくつかのオプション:

  • どういうわけか見逃している例外がスローされています
  • 自分が思っているコードをデバッグしていない (つまり、ビルドされたコードがソース コードと比べて古くなっている)

後者の可能性が最も高いのは、IMO です。

于 2009-12-30T19:46:27.190 に答える
1

どうやらあなたはコンストラクターの内部で例外を飲み込んでいるようです：

try {
    // Something.
} catch (Exception e) {
}

そんなことは絶対にしてはいけません。これにより、根本原因のデバッグと特定がはるかに困難になります。むしろthrow、または少なくとも実行しe.printStackTrace()ます。throws何らかの理由でこの節を使用したくない場合は、a RuntimeException(またはそのサブクラスの 1 つ) を使用することを検討してください。例えば

try {
    // Something.
} catch (Exception e) {
    throw new RuntimeException("Construction failed.", e); // Try to be more specific, e.g. IllegalArgumentException or so. Or just write robust code, i.e. nullchecks and so on.
}

または（ただし、私の意見では、あなたの場合にはあまり当てはまりません）：

try {
    // Something.
} catch (Exception e) {
    e.printStackTrace();
}
于 2009-12-30T19:49:51.743 に答える
1

問題を示すために簡単な例を作成しようとしていることは理解していますが、適切な型ステートメントをサンプル コードに追加すると、コンパイルされ、期待どおりに動作します。

ただし、元のコードベースでは、静的メソッドにブレークポイントを配置するだけで、それが呼び出されるかどうかを確認できます。

単純な質問かもしれませんが、実行していると思われるコードを実行していると確信していますか? つまり、すべてが再コンパイルされ、最新のソースからビルドされていますか?

于 2009-12-30T19:50:53.797 に答える
0

java.lang.Exceptionをキャッチしても問題がキャッチされない理由は、この場合は具体的すぎる可能性が高いためだと思います。java.lang.NoClassDefFoundErrorのようなエラーをキャッチするjava.lang.Throwableをキャッチしてみてください。これは、jar がどこかにない場合に頻繁に発生します。

于 2010-01-13T00:13:37.567 に答える