-2

私の最も強力なリードは、着信 XML を処理するコードが実際に無効または不完全なファイルを受け取っているため、DOM 解析に失敗しているということです。助言がありますか?

4

4 に答える 4

3

不完全なファイルは間違いなく探し始める場所です。ファイルを解析する直前にファイルを印刷して、パーサーに何が送信されているかを確認します。それが不完全であれば、それは明らかです。無効な場合は、少し検索する必要があります。

于 2008-09-17T17:03:30.910 に答える
2

私の最初の推測では、DOMを使用するコードは、DTDでオプションとしてマークされている要素を必須として扱っていると思います。

追加するために編集:つまり、DTDに対して検証しない限り、次のようなもの(dom4jを使用した例)がnull以外のものを返すことは期待できないということです。

doc.selectSingleNode("//some/element/in/a/structure");

もちろん、要素ナビゲーション呼び出しをつなぎ合わせている場合、または通常は戻り値を使用する前にチェックしない場合も同様です。

于 2008-09-17T17:09:00.273 に答える
1

NPEがスローされた場所を指すスタックトレースが必要です。これにより、nullになる可能性のある変数の数を絞り込むことができます。デバッガーやprintfを取得するのではなく、適切なチェックを追加して、エラーが検出されたらすぐに例外をスローすることをお勧めします。後で不思議な問題を避けるために入るのは良い習慣です。

于 2008-09-17T17:07:41.040 に答える
1

理想的には、デバッガー内でJavaアプリケーションを実行する必要があります。したがって、キャッチされない例外がスローされた場合、コールスタック、変数などを調べて、クラッシュの原因となった行と、使用されたnullのデータを正確に確認できます。

なんらかの理由でデバッガーを使用できない場合は、デバッグサポートを使用してアプリケーションをコンパイルし、この特定のエラーの例外ハンドラーを追加して、スタックトレースを出力します。繰り返しますが、これにより、クラッシュの原因となったファイルの行が正確に表示されます。

于 2008-09-17T17:08:15.017 に答える