点击这里获取存储过程P_Insert_New_BookTitle_2K的源代码。你可以看到，这个存储过程包含了非结构化的错误处理代码，这是我们在SQL Server 2005之前使用的方式。

　　我们已经先看到了存储过程P_Insert_New_BookTitle_2K中使用的代码。你顶多能说：“至少我们有异常处理。”下面的语句执行这个SQL Server 2000下的存储过程。

　　在用指定的参数执行存储过程时，对Authors表的插入失败了，因为佣金费率值无效。我们的约束检查发现了该无效值，我们可以看到如下错误信息：

　　Msg 547, Level 16, State 0, Procedure P_Insert_New_BookTitle, Line 23 The INSERT statement conflicted with the CHECK constraint "CHK_ValidateCommissionRating". The conflict occurred in database "Adventureworks2005", table "dbo.Authors", column 'CommissionRating'. The statement has been terminated.

　　这里的问题是我们不能阻止这些消息被送到客户端。所以判断哪里出错的重担就放到了客户端的头上。令人遗憾的是，在有些情况下，这样的结果对于一些不使用约束限制的应用程序可能足够了。

　　我们再来试一次，这次我们使用TRY……CATCH代码块。

　　点击这里获取存储过程P_Insert_New_BookTitle_2K5的源代码。在这段新改进的存储过程中，我们看到使用了TRY……CATCH代码块的结构化错误处理：

　　要注意SQL Server 2005异常处理代码是经过简化的，因此具有更好的可读性和可维护性。不需要剪切和粘贴异常处理代码，也不需要使用GOTO语句。执行该存储过程时，你可以看到如下结果：

　　我们用指定的参数执行存储过程，同样因为佣金费率值无效，对Authors表的插入失败了。错误发生时，程序执行流程跳转到了CATCH代码块，在CATCH代码块中我们回滚了事务，然后用SQL Server 2005自带的函数给Application_Error_Log表插入一行日志。

　　新的TRY……CATCH代码块无疑使编写处理错误代码更容易，它还可以在任何时候阻止错误信息发送到客户端。当然这可能需要T-SQL程序员的编程思维有一个转变，这是一个绝对有必要使用的特性。要记住迁移SQL Server 2000代码到SQL Server 2005时，如果程序的错误处理机制已经设计为旧的发送错误到客户端的方式，那你可能不得不修改应用程序了。从长远来看，我相信为这种潜在的问题付出努力重新设计是值得的。