私はデータベースをよく扱うクライアント コード モンキーです。これが私の対処法です。
SQL で発生する例外 (raiseerrors) は、呼び出し元に伝搬されます。これには、ref 制約、一意のインデックス違反、より深刻な問題などが含まれます。基本的に、データ操作を正常に行わせないものはすべて伝播する必要があります。
呼び出し元の C# には次のものが必要です:
catch (SQLException sqlEx)そして、必要に応じて例外を処理します。特定の SQLException ハンドラが必要です。これは重要です。
出力パラメータはエラー メッセージではなく、転送されるデータに関連していると考えているため、通常は出力パラメータには近づきません。さらに、SQL Server エラー コードの例外を調べて、必要なすべてのデータがその例外に含まれるようにすることもできます。
さらに、SQL Server の場合、「ビジネス タイプの例外」を発生させる可能性があるストアド プロシージャがあります。そのような場合、カスタム エラー番号 (50000 以上) を追加し、必要に応じてストアド プロシージャでそのエラーを発生させます。一般に、複雑さが増すため、これらを最小限に抑えようとしますが、場合によっては、それらが必要であることがわかりました.
ここで、クライアントは SQLException をキャッチしているため、例外で SQL Server によって返されたエラー コードを確認し、例外がキャッチされ、エラー番号が特定の値である場合に (必要に応じて) 特別なアクションを実行できます。これにより、カスタム エラー (>50000) に必要な場合に、エラー コードに基づいた二次レベルのエラー処理が可能になります。
これにより、DBA はカスタム エラーを発生させ、クライアント コードにそれらを処理する一貫した方法を持たせることもできます。 DBA は、クライアント コード モンキーに、カスタム エラーが何であるかを伝えて、それらに備えることができるようにする必要があります。
通常、リターン コードをエラー処理の目的で使用することはありませんが、どのように使用できるかはわかりますが、それはコード モンキー レイヤーでリターン コードを調べて処理するためのロジックが増えることを意味します。それらが問題である場合は、一貫して対処できるので、例外を返してほしいと思います。リターン コードも確認する必要がある場合は、複数の方法でエラーを処理できます。