TRY..CATCH Error_Line（）....行

Question

私はTry...Catchを習得しようとしているので、このサンプルはMSから提供されています。私は文法と出力を理解していますが（ほとんどの場合）、質問は1つあります：

出力にError_Lineが「4」と表示されます。これは問題ありませんが、GOとBEGIN TRYの間で改行を削除すると、Error_Lineが '3'と表示されます。私はちょうどここの論理を理解したい。

私が想像していることは、SQL ServerがGOの直後にバッチを開始することによって行を数えていることです。たとえその行が空白であっても、確かにこれを知らないのです。誰でも明確にすることはできますか？そのような理論が正しい場合、このような改行でスクリプトが書かれていれば、エラーを見つけるのが難しくなりませんか？

-- Verify that the stored procedure does not already exist. 
IF OBJECT_ID ('usp_GetErrorInfo', 'P') IS NOT NULL 
    DROP PROCEDURE usp_GetErrorInfo; 
GO 

-- Create procedure to retrieve error information. 
CREATE PROCEDURE usp_GetErrorInfo 
AS 
SELECT 
    ERROR_NUMBER() AS ErrorNumber 
    ,ERROR_SEVERITY() AS ErrorSeverity 
    ,ERROR_STATE() AS ErrorState 
    ,ERROR_PROCEDURE() AS ErrorProcedure 
    ,ERROR_LINE() AS ErrorLine 
    ,ERROR_MESSAGE() AS ErrorMessage; 
GO 
             --Line 1 
BEGIN TRY        --Line 2 
    -- Generate divide-by-zero error. --Line 3 
    SELECT 1/0;       --Line 4 
END TRY 
BEGIN CATCH 
    -- Execute error retrieval routine. 
    EXECUTE usp_GetErrorInfo; 
END CATCH; 

Answer 1

あなたは本当にエラーが内部ストアドプロシージャでスローまたは実行された動的なT-SQLステートメントがありますされ、特にERROR_LINE()、に頼ることはできません。

本当に正確なエラーラインが必要ですか？

1. 実際の生産コードでは、エラーの原因となった行の修正が、例のようにあまり明確でないことがあります。
2. 問題を解決するために容易になります。このように

エラーを再現するために、対応する入力パラメータを持つストアドプロシージャまたは関数をデバッグする方がよいでしょう。 SQLルーチンをデバッグするために：

1. だけでスクリプトをそれ
2. は
3. は、入力パラメータの前に宣言するとエラーに

の原因となる値でそれらを初期化し追加 dropと createものを取り除きます

基本的には、正確なエラーライン（正確な入力パラメータとルーチンの実行を簡単に行うことができます）ではなく、有用な2つのものがあります。

エラーの原因となっているルーティング

• （例えば、ユーザーに（これは分離テーブルを用いて行うことができる
同様にエラーの原因となっている入力パラメータをSP名を得ている usp_GetErrorInfo SPを追加のパラメータを追加することができ CATCH句にエラーを記録するために - あなたは、単純な挿入を、この情報を持つエラーに関するテーブル情報）

での入力パラメータは、再現し、その後、多くの場合、（問題を解決するために簡単になります） 。