Defensive Db Programming Chapter 08

Comments: 1 Comment
Published on: November 11, 2010

We are slowly getting to the end of this book by Alex Kuznetsov (Blog).  You can find more on this series by looking here.  We are now discussing chapter 8 and it is a good chapter.  This chapter delves into Error Handling.

While the use of TRY…CATCH certainly is the best way to handle errors in T-SQL, it is not without difficulties. (p. 259)

In this chapter, Alex discusses some of the problems associated with error handling and demonstrates how to resolve some of those problems.  We will also see how to use XACT_ABORT.

The first key to error handling is to prepare for unanticipated failure.  That is the crux of error handling.  We anticipate certain behaviors and code for that, anything else needs to be handled through error handling so we can see what has happened.  Code sometimes fails, and queries against the data can also fail on occasion – we need to plan for those failures.

When dealing with data modifications there are occasions when using explicit transactions is necessary due to the nature of the data modification – we would want to ensure that any and all changes to the data were rolled back.  There are other times when we would want to ensure that processing halts immediately when an error is encountered.  In such a scenario, XACT_ABORT comes in useful.  Note, however, that this setting is probably better set explicitly ON or OFF depending on the needs.

A recommendation in this chapter is to use client-side error handling for all but the simplest of error handling.  Error-handling is far more robust in other languages than it is in TSQL.  This is a recommendation that I support.  Error handling in TSQL has become better over time (i.e. with the addition of the TRY…CATCH) and is quite useful for some degrees of error handling.  One particular realm where error handling in TSQL is lacking is in the area of Code-Reuse.  The TRY…CATCH must be rewritten for each stored procedure for which you wish to enable error handling.

As always, this chapter covers some of the gotchas of error handling in TSQL and gives examples on how to implement as well as circumvent some of the problems.  Check it out!!

1 Comment - Leave a comment
  1. […] is down to the final two chapters of the book by Alex Kuznetsova.  Check out the previous chapter here.  The review of this book is certainly taking longer to produce than I had planned.  However, I […]

Leave a comment

Your email address will not be published. Required fields are marked *

November 2010
« Oct   Dec »


  • @SQLBarbarian: #SqlHelp Is there a way to extract out a version by ver compare report on view in a VS db project, to see all schema changes at a glance?
  • @SQLSteinar: @SQLTrooper @sqlcheesecake If all the free space is in the end of the file it could take almost zero logfile to shrink the datafile #sqlhelp
  • @SqlFerret: Can a rebuild full text search from a migrated database fill a 100gb transaction log (50gb), database #sqlhelp
  • @SQLSteinar: @TossingRazors No, not unless I can test and verify it myself first #sqlhelp
  • @SQLSteinar: @sql_r If you want to go bonkers, force nested loop join w table scan on table that doesn't fit in ram #sqlhelp
  • @sql_r: Anyone have a method to trash PLE? DROPCLEANBUFFERS doesn't affect it. Need something for test/demo I'm presenting. Thanks. #sqlhelp
  • @matt40k: Can DacFX create a sqlproj or just a .dacpac? #sqlhelp
  • @DaniSQL: Anyone know of a book/blog/white paper etc. on how a well run DBA team and (SQL Server)database infrastructure should look like? #sqlhelp
  • @DBA_ANDY: Making copy of table w/o PERSISTED column brings CHECKTABLE back down to "normal" - this fixes it but why is it happening? #sqlhelp (3/3)
  • @DBA_ANDY: at but it talks about indexes on computed columns - I don't have any indexes/stats on the columns #sqlhelp (2/3)

Welcome , today is Tuesday, October 6, 2015