2

OUT パラメータを返すプロシージャがあります。

procedure foo (in_v IN INTEGER, out_v OUT integer)
BEGIN
...
EXCEPTION
  WHEN OTHERS THEN
    --sh*t happend
    out_v := SQLCODE;
END

すべてがうまくいけば、そのパラメータは 0 になり、何か問題が発生した場合は <> 0 になります。

ここで、途中で sh*t が発生すると、例外がスローされます。

SQLCODE 値を OUT パラメータに代入してもよろしいですか? それとも、これはコードの匂いと見なされ、プログラミング コミュニティから追放されますか?

前もって感謝します。

4

4 に答える 4

11

エラーの追加処理がない場合は、おそらくそれをお勧めしません。このアプローチでは、とにかく各呼び出し元が out パラメータの値を調べる必要があります。また、発信者がそれを忘れると、深刻な問題が最初は見過ごされ、別の場所でデバッグが困難な問題が発生する可能性があります。

ここで OTHERS を単にキャッチしない場合は、呼び出し元が明示的にキャッチする必要があることを確認します。これにより、はるかにクリーンでデバッグが容易になります。

于 2009-12-21T14:49:10.120 に答える
4

大丈夫かどうかは、それで何を達成しようとしているかによると思います。どのような問題を解決しようとしていますか、またはどのような要件を満たそうとしていますか?

エラーが発生した場合の通常の動作は、通常の機能中に発生する可能性があるエラーを適切に処理し、予期しないエラーが発生することを許可することです。したがって、これは奇妙に見えます。

于 2009-12-21T14:45:05.080 に答える
2

大丈夫ですが、お勧めしません。このようにすることで、呼び出し元のコードに非標準のエラー処理を強制することになります。コードを呼び出したのが自分だけで、エラー コードを確認することを忘れない場合は、これで問題ありません。ただし、複数のプログラマーがいる大規模なシステムでコーディングしている場合は、仲間のプログラマーに親切にし、言語でサポートされている例外処理の標準的な方法に従う必要があると思います。

そのルートをたどることに決めた場合は、SQLERRM も返してください。エラー テキストがないと、通過するエラー コードしかありません。サードパーティ製ソフトウェアの何百ものアプリケーション エラーの "-20001" を何年もキャッチした後、SQLERRM が重要になることがよくあります。

于 2009-12-21T18:18:59.200 に答える
0

このコーディングスタイルは、いくつかの理由からお勧めできません。

まず、エラーと例外を混在させることは悪い習慣であり、戻り値と例外を混在させることはさらに悪い習慣です。例外は、例外的な状況を追跡することを目的としています。メモリ不足の問題や変換の問題など、通常のプログラミングではまったく予期しないことで、通常はすべての呼び出しサイトでハンドラーを作成する必要はありませんが、何らかのレベルで対処する必要があります。

コーディングスタイルの2番目の心配な側面は、例外が発生したときにコードが効果的に言っていることです。コードは呼び出し元に何か悪いことが起こったことを通知しますが、SQLCODEを除くすべての例外情報を喜んで破棄します。

于 2010-01-06T22:40:51.477 に答える