我遇到一个存储过程，在更新尝试后立即有以下错误处理块。以下是SP的最后一行。T-SQL中的TRY CATCH块

这样做有什么好处吗？在我看来，好像这个代码只是重新抛出没有任何附加价值而被捕获的同样的错误，并且如果Try Block完全被忽略，代码可能会表现为100％。

如果TRY块被省略，那么结果SP的行为会有什么不同吗？

BEGIN CATCH 

SELECT @ErrMsg = ERROR_MESSAGE(), @ErrSev = ERROR_SEVERITY(), @ErrState = ERROR_STATE() 
     RAISERROR (@ErrMsg, @ErrSev, @ErrState) 

END CATCH

来源

2011-02-14 ChadD

我能想到的唯一区别是，行号信息和错误号码信息会更准确，因为没有`CATCH`抛出一个新的异常，所以它实际上似乎减去了值，据我所知。 .. – 2011-02-14 14:44:41

我总是喜欢在前端有一个自定义的错误消息，而不是sql生成的错误消息。这种方式会给你你理解和提到的逻辑和技术错误。 – Chris 2011-02-14 15:08:48

除非返回的任何消息部分出现“线路错误”，否则会引用RAISERROR行而不是错误实际发生的行，则不会有任何区别。做这件事的主要原因是@Chris说，让您以编程方式使用/操作错误数据。

来源

2011-02-14 14:49:08

我们通常在我们的存储过程做的是写catch块这样

BEGIN CATCH 
    DECLARE @i_intErrorNo int   
    DECLARE @i_strErrorMsg nvarchar(1000)   
    DECLARE @i_strErrorProc nvarchar(1000)   
    DECLARE @i_intErrorLine int   

    SELECT @i_intErrorNo=Error_Number()   
    SELECT @i_strErrorMsg=Error_Message()   
    SELECT @i_strErrorProc=Error_Procedure()   
    SELECT @i_intErrorLine=Error_Line() 

    INSERT INTO error table ////// Insert statement. 

END CATCH

这是我们用来做存储错误的东西。为了给用户正确的消息，我总是使用输出参数来存储过程来显示错误的详细/必需的原因。

来源

2011-02-14 14:43:04 Chris

如果你看一下在msdn page for RAISERROR然后就看到这个一般描述：

生成错误消息和启动错误处理的会议。 RAISERROR可以或者引用存储在sys.messages目录视图中的用户定义消息或动态构建消息。该消息作为服务器错误消息返回给调用的应用程序或TRY ... CATCH构造的关联CATCH 块。

看起来“调用应用程序”会出现错误信息。这可能是存储过程的创建者只需要报告错误消息，严重性和状态，并且不能添加其他选项。这可能是由于安全问题，或者是由于调用应用程序不需要知道额外的信息（可能是冗长或过于详细的）。

来源

2011-02-14 14:47:24

所有“额外信息”都包含在由ERROR_MESSAGE（）返回的字符串中。混淆这一点，你必须用你自己的更少的消息来替换它，这个例程不会这样做。 – 2011-02-14 14:50:38

存在一个细微的差异，如下所示。

首次设置如下：

CREATE TABLE TMP 
(ROW_ID int NOT NULL, 
    ALTER TABLE TMP ADD CONSTRAINT PK_TMP PRIMARY KEY CLUSTERED (ROW_ID) 
) 
GO 
CREATE PROC pTMP1 
AS 
BEGIN TRY 
    INSERT INTO TMP VALUES(1) 
    INSERT INTO TMP VALUES(1) 
    INSERT INTO TMP VALUES(2) 
END TRY 
BEGIN CATCH 
    DECLARE @ErrMsg varchar(max)= ERROR_MESSAGE(), 
      @ErrSev int = ERROR_SEVERITY(), 
      @ErrState int = ERROR_STATE() 
     RAISERROR (@ErrMsg, @ErrSev, @ErrState) 
END CATCH 
GO 
CREATE PROC pTMP2 
AS 
    INSERT INTO TMP VALUES(1) 
    INSERT INTO TMP VALUES(1) 
    INSERT INTO TMP VALUES(2) 
GO

现在运行以下命令：

SET NOCOUNT ON 
DELETE TMP 
exec pTMP1 
SELECT * FROM TMP 
DELETE TMP 
exec pTMP2 
SELECT * FROM TMP 
SET NOCOUNT OFF 
--Cleanup 
DROP PROCEDURE pTMP1 
DROP PROCEDURE pTMP2 
DROP TABLE TMP

你应该得到以下结果：

Msg 50000, Level 14, State 1, Procedure pTMP1, Line 12 
Violation of PRIMARY KEY constraint 'PK_TMP'. Cannot insert duplicate key in object 'dbo.TMP'. The duplicate key value is (1). 
ROW_ID 
----------- 
1 

Msg 2627, Level 14, State 1, Procedure pTMP2, Line 4 
Violation of PRIMARY KEY constraint 'PK_TMP'. Cannot insert duplicate key in object 'dbo.TMP'. The duplicate key value is (1). 
The statement has been terminated. 
ROW_ID 
----------- 
1 
2

注意，TRY..CATCH版本没有执行第三个INSERT声明，而pTMP2 proc没有。这是因为一旦发生错误，控制就跳转到CATCH。

注意：pTMP2的行为受XACT_ABORT设置的影响。

结论

使用TRY..CATCH所证实的好处取决于你如何管理自己的事务边界。

如果您回滚任何错误，则更改将被撤消。但是这并不能消除附加处理等副作用。注意：如果不同的会话使用WITH(NOLOCK)同时查询TMP，它甚至可能会观察到临时更改。
但是，如果您不打算回滚事务，则可能会发现该技术对于防止应用某些数据更改（尽管存在较早的错误）非常重要。

来源

2015-05-22 10:43:21

T-SQL中的TRY CATCH块

回答

结论

相关问题