As for error handling: religious wars and arguments about the use of the comic sans typeface are right up there with error handling compared to exception handling. While my preference is that expected errors should be handled cleanly and neatly and everything else is, well, an exception, it really doesn't matter as long as it's documented well enough. This ties right in back to the point about the (lack of) documentation.
What I hate is when people try to do too much error handling, but do it poorly, and their code ends up swallowing or obfuscating the actual error that happened, making it harder to troubleshoot.
What's annoying is when different groups can't agree on what should be a hard error and what should be some kind of return message to be handled by the calling party. Working on a project now and several different groups of coders handle errors in spectrum from throw a hard error, some kind of error code in the returns, to success with all negative return values, to success with an obscure nested message indicating something might be wrong to simply success regardless of what happened :angry:
Heh... you forgot about just letting SQL Server handle the errors, which is normally well enough.
This is why we have standards where I work. Saves a whole lot on arguments especially when new folks enter the house. The rule is, if you have a better idea, let's talk about it and, if it's a good thing, we'll implement it and change the standards. In the meantime, follow the standards.