Question

For Asp.net web applications, is it best to:

1. trap errors within sql stored procedures and test for a return value in the code or
2. just let the error occur in sql (dont handle it) and rely on ado.net raising the errors within the code.

What are the best practises here?

Answer 1

A general rule that applies here is to catch the error as near the source as possible. SQL Server now has ‘try … catch …’ error trapping syntax. So use it. The overhead of the little bit of extra code is insignificant, and if you have multiple statements in your SP, you can adapt the string in RAISERROR to help localize the problem.

In the interface, it shouldn’t be difficult to trap the SP error event and handle it the same way you handle other error trapping in your procedural code.

This is one of the more neglected ‘best practices’ in stored procedures, and it’s even more important than in ‘regular’ code because it’s trickier to use a step=through debugger.

One useful pattern is to handle this in your SP the same way you it expect it to be handled in any other opaque SDK library.