Try-catch should capture the parse errors - by Carlos Fatureto1

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


17
0
Sign in
to vote
ID 496758 Comments
Status Closed Workarounds
Type Suggestion Repros 0
Opened 10/8/2009 3:39:30 PM
Access Restriction Public

Description

I think Try-catch should capture the parse errors, 
because it's been unsafe to use it. 
The "rolback tran" is always inserted inside the catch block
and in case some procedure tries to access an inexistent 
object the transaction will remain open, blocking the other users. 


Example:
create table test1 (c1 int)
GO

create procedure usp_test
as
begin

   begin try
      begin tran

      insert into test1 (c1) values (10)

      update test5 set c1 = 50 --this table does not exist

      commit tran
   end try
   begin catch
      rollback tran

      raiserror ('error', 16, 1)
   end catch

end
go


exec usp_test --THE EXEC WILL FAIL, BUT THE TRANSACTION WILL REMAIN OPEN


--EXECUTE IN OTHER SESSION (THE SELECT WILL BE BLOCKED) 
select * from test test1 
Sign in to post a comment.
Posted by Umachandar [MSFT] on 3/18/2011 at 2:07 PM
Hello Carlos,

Thank you for submitting this suggestion, but we're trying to clean house and remove items we feel we will likely not address given their priority relative to other items in our queue. We believe it is unlikely that we will address this suggestion, and so we are closing it as “won’t fix”.

This cleaning will help us focus on the high-priority items that we feel need to get done, and we hope that it help provide better clarity to you about the issues we will (and won't) address.

--
Umachandar, SQL Programmability Team
Posted by Umachandar [MSFT] on 10/12/2009 at 3:28 PM
Hi Carlos,
Thanks for your feedback. We will consider improving the catch block functionality/behavior for a future version of SQL Server.

--
Umachandar, SQL Programmability Team