Defensive Database Programming - Red Gate Software

More documents

Recommendations

Info

Chapter 8: <strong>Defensive</strong> Error HandlingNow return to Tab 1, and execute the commented UPDATE against the Codes table,from Listing 8-10, including the COMMIT. As soon as this code tries to execute, adeadlock is detected. SQL Server chooses our stored procedure execution from Tab 2 asthe deadlock victim, since we deliberately contrived for this to be the case. Thetransaction in our TRY block is rolled back, but then our CATCH block is executedand we try to execute our stored procedure again. This time, since Tab 1 has nowcommitted, the modification succeeds. The output from Tab 2 is shown in Listing 8-12.Rolling backEncountered a deadlock(1 row(s) affected)(1 row(s) affected)Modifications succeededCode Description---------- -----------------------------------IL ?(1 row(s) affected)Code---------- -----------------------------------ILIL, Ill.IL Illinois, ?Listing 8-12. Tab 2, output from execution of the stored procedure.Note also, however, that the UPDATE we execute from Tab 1 is "lost;" its changes wereoverwritten when the retry succeeded.From these examples, we have learned the following:• if several modifications must succeed or fail together, use transactions, and roll themodification back, as a unit, if any one of them fails272
Chapter 8: <strong>Defensive</strong> Error Handling• always anticipate that any modification may fail; use XACT_ABORT to ensure thattransactions roll back after a failure; alternatively, we can wrap our transactions inTRY blocks, and roll them back in CATCH blocks.Unfortunately, there are a few problems with using TRY…CATCH error handling that weneed to discuss. In the next section, we'll look at some ways in which TRY…CATCH errorhandling is limited and its behavior surprising. We'll then see what we can achieve whenusing C# for error handling, instead of T-SQL.TRY…CATCH GotchasT-SQL is not really an efficient language for error handling, and is certainly less robustthan error handling in client-side languages such as C++, Java, and C#. As such, althoughin most cases TRY…CATCH blocks work as expected and catch errors as they should,there are also quite a few "special cases" that we need to know about, where the behavioris not as we might expect.Furthermore, TRY…CATCH error handling does not really facilitate code reuse. If wewant to use this approach in another stored procedure, we cannot fully reuse ourT-SQL error handling code; we have to cut and paste much of it into that other storedprocedure. This, as we proved in Chapter 5, Reusing T-SQL Code, is a recipe for bugsand inconsistencies.Over the following sections, we'll discuss some of the special cases of which we need tobe aware when using TRY…CATCH.Re-throwing errorsIn many cases, we do not wish to handle certain errors in our CATCH block, and insteadwant to re-throw them, so that they are handled elsewhere. In our previous example,where we wished to retry execution after a deadlock, all other errors were handled bycapturing the error message, using the ERROR_MESSAGE function, and re-throwingthe error using RAISERROR. However, the error message on its own is generallyinsufficient; we should also retrieve the information from the ERROR_LINE,ERROR_NUMBER, ERROR_PROCEDURE, ERROR_SEVERITY, and ERROR_STATEfunctions, declare variables to store this information, and then use RAISERROR to273
Page 5 and 6:
Chapter 2: Code Vulnerabilities due
Page 7 and 8:
Enforcing Data Integrity in the App
Page 9 and 10:
About the AuthorAlex Kuznetsov has
Page 11 and 12:
IntroductionResilient T-SQL code is
Page 13 and 14:
IntroductionCh. 02: Code Vulnerabil
Page 15 and 16:
IntroductionSpecific examples demon
Page 17:
IntroductionWhat this book does not
Page 21 and 22:
Chapter 1: Basic Defensive Database
Page 24 and 25:
Page 26 and 27:
Page 28 and 29:
Page 30 and 31:
Page 32 and 33:
Page 34 and 35:
Page 36 and 37:
Page 38 and 39:
Page 40 and 41:
Page 42 and 43:
Page 44 and 45:
Page 46 and 47:
Page 48 and 49:
Page 50 and 51:
Page 52 and 53:
Page 54 and 55:
Page 57 and 58:
Chapter 2: Code Vulnerabilitiesdue
Page 59 and 60:
Page 61 and 62:
Page 63 and 64:
Page 65 and 66:
Page 67 and 68:
Page 69 and 70:
Page 71 and 72:
Page 73 and 74:
Page 75:
Page 78 and 79:
Chapter 3: Surviving Changes to Dat
Page 80 and 81:
Page 82 and 83:
Page 84 and 85:
Page 86 and 87:
Page 88 and 89:
Page 90 and 91:
Page 92 and 93:
Page 94 and 95:
Page 96 and 97:
Page 98 and 99:
Page 100 and 101:
Page 102 and 103:
Page 104 and 105:
104
Page 106:
Chapter 4: When Upgrading Breaks Co
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123 and 124:
Page 125 and 126:
Page 127 and 128:
Page 130 and 131:
Page 132 and 133:
Chapter 5: Reusing T-SQL CodeThe Da
Page 134 and 135:
Chapter 5: Reusing T-SQL CodeIt is
Page 136 and 137:
Chapter 5: Reusing T-SQL CodeAverag
Page 138 and 139:
Chapter 5: Reusing T-SQL CodeBEGINS
Page 140 and 141:
Chapter 5: Reusing T-SQL CodeWe als
Page 142 and 143:
Chapter 5: Reusing T-SQL CodeLet's
Page 144 and 145:
Chapter 5: Reusing T-SQL CodeStateC
Page 146 and 147:
Chapter 5: Reusing T-SQL CodeStateC
Page 148 and 149:
Chapter 5: Reusing T-SQL CodeBEGIN
Page 150 and 151:
Chapter 5: Reusing T-SQL CodeSELECT
Page 152 and 153:
Chapter 5: Reusing T-SQL CodeReusin
Page 154 and 155:
Chapter 5: Reusing T-SQL CodeIt is
Page 156 and 157:
Chapter 5: Reusing T-SQL CodeINSERT
Page 158 and 159:
Chapter 5: Reusing T-SQL CodeListin
Page 160 and 161:
Chapter 5: Reusing T-SQL CodeUnique
Page 162 and 163:
162
Page 164 and 165:
Chapter 6: Common Problems with Dat
Page 166 and 167:
Page 168 and 169:
Page 170 and 171:
Page 172 and 173:
Page 174 and 175:
Page 176 and 177:
Page 178 and 179:
Page 180 and 181:
Page 182 and 183:
Page 184 and 185:
Page 186 and 187:
Page 188 and 189:
Page 190 and 191:
Page 192 and 193:
Page 194 and 195:
Page 196 and 197:
Page 198 and 199:
Page 200 and 201:
Page 202 and 203:
Page 205 and 206:
Page 207 and 208:
Page 209 and 210:
Chapter 7: Advanced Use ofConstrain
Page 211 and 212:
Chapter 7: Advanced Use of Constrai
Page 213 and 214:
Page 215 and 216:
Page 217 and 218:
Page 219 and 220:
Page 221 and 222: Chapter 7: Advanced Use of Constrai
Page 255 and 256: Chapter 8: Defensive ErrorHandlingT
Page 257 and 258: Chapter 8: Defensive Error Handling
Page 271: Chapter 8: Defensive Error Handling
show all

Defensive Database Programming - Red Gate Software

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?