I kinda disagree with #27 and 30, though I guess it depends on what version of SQL Server we're talking about. I wouldn't use @@ERROR, I'd use ERROR_NUMBER() and the other ERROR* functions instead. Plus I'd wrap things in a BEGIN TRY/BEGIN CATCH and deal with error and pending transaction in the CATCH (oh that reminds me...you don't mention how to check for/deal with deal with an uncommitable transaction)..

In #30, what does "properly return" mean? Output parameters? A custom error message? Why bother? The client will receive the error message (unless you swallow it in a CATCH, which you probably shouldn't do...I generally re-THROW the original error).

Maybe you should qualify this as being best practices for you. 🙂