If you put a select query inside a try/catch-block, you have the possibility to handle possible runtime errors in the query without having the errors thrown back to the client. This query will for example throw an error: SELECT 1/0 as DivisionByZeroColumn Byt if you do BEGIN TRY SELECT 1/0 as DivisionByZeroColumn END TRY BEGIN CATCH PRINT 'error occured' END CATCH You won't get the error thrown. You will however still get a result set back, which might or mig not be what you desire. In the query above, you will get a result set with the column DivisionByZeroColumn, but with no rows. Therefore, the client might think the query executed successfully but did not return any rows. You probably want to handle the error by logging to an error log, and then still throw an error back to the client. At least I personally want errors from a database query to be thrown to the client, so the client knows what happened and can take action.
@magnus_ahlkvist answer is 100% correct (already +1). I just want to add a general reason why you should have the TRY/CATCH there. I try to standardize my code as much as I can. When working on large projects I'll do this through templates. Which means, when laying out a template for stored procedures, I'll put in a generic error handling structure that is automatically there for whatever type of query you're running. So, even though, in some situations, a SELECT query doesn't really need error handling (assuming a whole ton here when I say that) but most of mine get them anyway because I'm working from that standard template.