sql server の sql 文のエラーを .NET の画面に表示したい。

お世話になっております。

ストアドプロシージャ内でエラーが発生して CATCHしたときのエラー内容を .NET 側の画面に表示したいので、RETURN ?
でエラー内容を返したいのですが、実装方法がわかりません。。
どなたかアドバイスをご教示ください。

＜環境＞
・Windows １０
・Sql server management studio 18.5
・Docker
・.NET Framework　（ASP.NET Web Forms）

ストアド自体はエラーを返す方法以外は完成しております。
エラーを返す方法（.NET
側で取得可能な返し方）をご教示頂きたいです。

sql
1BEGIG TRY
2  
3  BEGIN TRANSACTION
4
5
6   処理コード
7
8　COMMIT TRANSACTION
9END TRY
10
11BEGIN CATCH
12 ROLLBACK TRANSACTION
13
14 -- ここキャッチしたエラーを .net 側に返す方法
15 -- 現状
16 PRINT ERROR_LINE();
17 PRINT ERROR_MESSAGE();
18
19END CATCH
20RETURN
21

宜しくお願い致します。

退会済みユーザー

2020/07/27 01:23

> sql server の sql 文のエラーを .NET の画面に表示したい。質問者さんの言う「.NET の画面」って何ですか？

kotodama

2020/07/27 01:37

.NET の画面についてですが、 .NETで作成したアプリケーションの画面にストアドから返ってきたエラー情報を表示させたいです！

退会済みユーザー

2020/07/27 01:56 編集

> .NETで作成したアプリケーションの画面にストアドから返ってきたエラー情報を表示させたいです！その「アプリケーション」とは何なのですか？ Windows Forms? WPF? コンソールアプリ？ ASP.NET Web Forms? ASP.NET MVC? その他？　それを書かないと・・・あと、ストアド自体は完成していて、エラー情報はパラメータを使って渡せるようになっているのですか？上の情報は質問欄を編集して追記してください。コメント欄は初期画面では開いてないので見ない人がいますから。

kotodama

2020/07/27 02:10

ありがとうございます。 ASP.NET Web Forms　です。ストアドはエラーを .net 側に返す方法以外は完成しております。

退会済みユーザー

2020/07/27 02:27

ASP.NET のタグをつけてください。

kotodama

2020/07/27 02:44

ありがとうございます。タグも追記しました！

行動規範の内容に同意します

回答3件

ベストアンサー

ERROR CATCH部分でTHROWにより例外を発生させれば、通常のSQL実行時エラーと同様に(SqlException クラス等）処理できます。

参考
SQL Server で意図的にエラーを起こす

例外をカスタマイズしたい場合は、FORMATMESSAGEを併用します。

投稿2020/07/27 04:00

編集2020/07/27 04:07

sazi

総合スコア25327

kotodama

2020/07/27 07:13

ありがとうございます！ THROW で例外を発生させてそれを SqlException で　キャッチする方法があるんですね！勉強になります！ THROW で投げられるエラー内容はストアド処理の中で発生したエラー内容となるのでしょうか？それとも　THROWは投げられるエラー内容がきまっているのでしょうか？

sazi

2020/07/27 07:16 編集

THORWだけだと、例外の再開となり、発生した例外情報がそのまま返却されます。リンク先には例なども記載されていますので、確認してみてください。

kotodama

2020/07/27 07:53

なるほど！ありがとうございました！

退会済みユーザー

2020/07/27 08:06

SqlException で拾うなら、ストアドの中で例外処置などしないで（try - catch など一切しないで）、.NET のコード内で例外処置した方が良いのでは？　トランザクションに束ねて例外が出たらロールバックするというのも .NET のコード内で処理可能です。そもそも、try - catch は原則的には書くべきではないですし。

sazi

2020/07/27 08:10

@SurferOnWwwさん > try - catch は原則的には書くべきではないですし。とはどういった理由からでしょうか？　後学の為ご教示下さい。

退会済みユーザー

2020/07/27 08:58

catch して何ができるのかが問題です。予測できないもしくは予測はできても何の対応もできない「例外」（例えば DB サーバーダウン）が発生した場合は、ユーザーがそのまま作業を続けて事態を悪化させないためにも、例外をランタイムに拾わせてアプリケーションを停止させるべきです。ユーザーへの通知が必要なら集約的例外処置という手段が利用できます。

sazi

2020/07/27 09:01 編集

「例外処理は分散させるべきではない」、というのが「try - catch は原則的には書くべきではない」というコメントの趣旨で宜しいですか？

退会済みユーザー

2020/07/27 09:05

違います。上のコメントをよく読んでいただければと思います。

sazi

2020/07/27 09:10

分かりません。 try - catchを使用してもTHOROWすればアプリケーション側で例外を拾う事はできると思うのですが。

sazi

2020/07/27 09:13

例外を発生させて、Try catchで分岐させるような事は珠に使用したりするので気になります。

退会済みユーザー

2020/07/27 09:19 編集

> try - catchを使用してもTHOROWすればアプリケーション側で例外を拾う事はできると思うのですが。 catch しなければ throw する必要もないのですけど？

退会済みユーザー

2020/07/27 09:18

> 例外を発生させて、Try catchで分岐させるような事は珠に使用したりするので気になります。 SQL Server のストアド単独で考えた場合は分かりませんけど、ASP.NET Web Forms アプリで ADO.NET を使って SQL Server を操作するような場合はそういうことは、自分の知る限りですが、あり得ないことです。

sazi

2020/07/27 09:22 編集

> catch しなければ throw する必要もないのですけど？それはそうですけど、例外にしたい場合とそのまま終了させる場合などでは、catchを使用するとコードが少なくて済みますし。

sazi

2020/07/27 09:21

Web Formsを使用した場合という事ですか。ご教示ありがとうございました。

退会済みユーザー

2020/07/27 09:22

> 例外にしたい場合とそのまま終了させる場合などでは、catchを使用するとコードが少なくて済みますし。上に書きましたように「例外」は「予測できないもしくは予測はできても何の対応もできない」ということで、アプリは終了させるのが基本と思います。

sazi

2020/07/27 09:28

例外の定義とその扱いについての認識違いという事なのでしょうね。

退会済みユーザー

2020/07/28 00:58

今更ながらのレスですみません。見逃してました。 > 例外の定義とその扱いについての認識違いという事なのでしょうね。そうですね、本に書いてあったことですが、必ずしも「例外」＝「予測できないもしくは予測はできても何の対応もできない」ではないという例を思い出しました。その例は、ユーザー登録の際のユーザー ID のダブりを PK 制約違反で検出し、ユーザーに ID を変更して再登録を促すような場合、try - catch で SqlException をキャッチし、SqlException.Number が 2627（PK 制約違反）なら処理続行、それ以外なら throw してランタイムに拾わせてアプリケーションを停止・・・というものでした。でもやはり上に書いた「そもそも、try - catch は原則的には書くべきではない」という自分の意見は変わらないのですが。ちなみに、トランザクションに束ねて例外が出たらロールバックするというのも .NET のコード内で try - catch を使わずに try - finally または using 句を使って処理可能です。（未コミットのトランザクションは SqlConnection を Close する際ロールバックされますので）

sazi

2020/07/28 01:05

SurferOnWwwさんの「try - catch は原則的には書くべきではない」とは.NETでの話ですか？私は、あくまでストアドでの使用についてお聞きしていたつもりでした。

退会済みユーザー

2020/07/28 01:33

>「try - catch は原則的には書くべきではない」とは.NETでの話ですか？質問は「.NET Framework　（ASP.NET Web Forms）」の話ということですので .NET での話（原則、例外は catch せず、.NET ランタイムに拾わせてアプリを停止）をしています。 > 私は、あくまでストアドでの使用についてお聞きしていたつもりでした。自分はストアドは無知に近いのでハズレかもしれませんが、ストアド単独でも try - catch による問題（例えば例外を握りつぶしてなかったことにしてしまうとか）は生じうると思っているのですが・・・　 sazi さんが言われる「例外を発生させて、Try catchで分岐させるような事は珠に使用したりする」ということがストアドでは一般的ということであれば失礼しました。

sazi

2020/07/28 02:01 編集

私も.Netにはそれほど詳しくありませんが、例外の扱いについてはストアドに限らず、どんな言語に関しても同じで、機能として使い分けるのがスタンスです。以下が考え方として近いものです。「もう少し例外を使用しても良いのではないか...」 https://qiita.com/MasayaMizuhara/items/98c0d490f1633d9b636f 例外を握りつぶすとかのデメリットは視野には入っていませんけど。

行動規範の内容に同意します

以下の記事は ASP.NET Web Forms アプリでストアドプロシージャを使っている例です。ページャー用のストアドプロシージャですので、質問者さんがやりたいこと（エラーメッセージを返して表示する）そのものズバリではありませんが、参考にはなると思います。

カスタムページャー
http://surferonwww.info/BlogEngine/post/2010/08/25/Custom-pager.aspx

上の記事の「ストアドプロシージャ」と「aspx ファイル」の CreateDataSource メソッドのコードに注目してください。

「ストアドプロシージャ」では @pageCount int OUTPUT というパラメータを設定し、ページ総数を計算して返すようになっています。

「aspx ファイル」の CreateDataSource メソッドでは ADO.NET を使って「ストアドプロシージャ」を動かして、パラメータ @pageCount からページ総数を取得しています。

質問者さんのケースでは、@pageCount に代えてエラーメッセージを返すパラメータを設定し、CreateDataSource メソッドと同様な形で ADO.NET を使ってストアドプロシージャを動かせば望むことができるのではないでしょうか？

投稿2020/07/27 02:26

退会済みユーザー

総合スコア0

kotodama

2020/07/27 02:37

ありがとうございます。ご丁寧に詳しくご教示頂きありがとうございます。エラーメッセージを返すパラメータを　OUTPUTで準備をしてそれに ERROR_MESSAGE() などを代入して返してみます！　その返したものを .net 側で取得して値を使用していきます！ありがとうございます！

行動規範の内容に同意します

どのようにしてストアドを呼び出しているのか知りませんが、「ストアドプロシージャからデータを返す」は参考になりませんか？

投稿2020/07/27 02:08

YAmaGNZ

総合スコア10505

kotodama

2020/07/27 02:13

ありがとうございます。こちら確認しておりました。 OUTPUTを使用すれば処理が終了した時に、値が返るそうなので、そちらでエラー内容は返せそうです。初歩的な質問なのですが、 sql server management studio の　ストアドを実行した際に、結果タブに表示されていれば .netなどから取得可能なのでしょうか？

行動規範の内容に同意します

あなたの回答