<p>I'd like know what people think about using RAISERROR in stored procedures to pass back user messages (i.e. business related messages, not error messages) to the application.  </p>

<p>Some of the senior developers in my firm have been using this method and catching the SqlException in our C# code to pick up the messages and display them to the user.  I am not happy with this method and would like to know how other people deal with these types of user messages from stored procs.</p>

If it can't be checked/caught earlier it might be difficult to do anything else.
I've had to write a raiseerror in a procedure I wrote and used as a constraint on inserting/updating a table because it was the 'last stop' for the data and I had to check it there.
I think in general if you are getting errors back from the DB.. its a pain in the butt and harder to give 'nice' feedback to the user without a lot of effort, but sometimes you just don't know until you insert/update :P