Also, you can take a look at what happens in your example when you change the proc dbo.spTryTestA:

create proc dbo.spTryTestA

as

--

begin try

raiserror('spTryTestA:1', 0, 1)

end try

begin catch

raiserror('spTryTestA:1 failed', 0, 1)

end catch

begin try

raiserror('spTryTestA:2', 16, 1)

end try

begin catch

raiserror('spTryTestA:2 failed', 0, 1)

end catch

begin try

raiserror('spTryTestA:3', 0, 1)

end try

begin catch

raiserror('spTryTestA:3 failed', 0, 1)

end catch

--(end)

go

This returns the same results either way. The issue in your example is that you've got a call to a ghetto proc within a TRY block. Now, there is nothing to be ashamed of ... we all have old code around that doesn't truly have error handling (checking @@ERROR is not proper error handling), but you can't make calls from that code from within a TRY block if you don't want the errors in the code to bubble up to the TRY. If you want to do execute legacy code, it's a pretty simple matter to move the call outside the TRY block.

Now, if your original stated opinion was that TRY...CATCH doesn't work well to make calls to archaic procs then I would wholly agree.