this article http://www.novicksoftware.com/tipsandtricks/tips-erorr-handling-in-a-stored-procedure.htm makes this claim about SQL Server development: "errors must be checked after every sql statement of interest". The fairly vague online descriptions of the sql debugger for TSQL neither refute nor support this claim.
So, it it really the case that an "easy to debug" stored procedure is one that has 50% of its code dedicated to detecting errors? Or are there better ways to do it, that could come closer to the sort of ease of finding crashes that we are familiar with in stack trace based debugging in modern programming environments?
Is this an area that calls for creating clever new tools to fill the gaps left by imperfection of the existing programming environment or one that calls for me to get with the program and learn some well known state-of-the-art way of getting this stuff done?
ETA: got it on the try-catch, thanks. In fact, to expand on that, here Recording SQL Server call stack when reporting errors is a discussion of how to emulate stack trace since apparently stack trace is not yet supported by SQL Server. Well, at least that's how it can be emulated in your own codebase written after reviewing the article - a legacy codebase without all this stuff would be harder to deal with.