CATCH block question

Hello,
With the new TRY - CATCH block feature in 2005, is there any way for
the calling application to know about errors unless I use RAISERROR'
The reason I ask is, I'd like to start using the new TRY - CATCH
syntax, but I don't know if our code is set up to receive the specific
error codes such as ERROR_MESSAGE or ERROR_SEVERITY (as shown below).
In fact, I don't even know if our apps are set up to handle return
codes. I think the way things have generally worked is - the stored
procedure is just allowed to break, with no error handling at all.
DECLARE @.ErrMsg nvarchar(4000), @.ErrSeverity int
SELECT @.ErrMsg = ERROR_MESSAGE(), @.ErrSeverity = ERROR_SEVERITY()
RAISERROR (@.ErrMsg, @.ErrSeverity, 1)
So, I'm wondering, is it possible to use TRY - CATCH block WITHOUT
using RAISERROR, but still have the calling app know about it?
If not, that means we have to rewrite a lot of code, which is not
desireable.
ThanksHi
You could return a status value, but your client code should always cater
for RAISERROR and other scenarios where the procedure does not return a value.
John
"tootsuite@.gmail.com" wrote:
> Hello,
> With the new TRY - CATCH block feature in 2005, is there any way for
> the calling application to know about errors unless I use RAISERROR'
> The reason I ask is, I'd like to start using the new TRY - CATCH
> syntax, but I don't know if our code is set up to receive the specific
> error codes such as ERROR_MESSAGE or ERROR_SEVERITY (as shown below).
> In fact, I don't even know if our apps are set up to handle return
> codes. I think the way things have generally worked is - the stored
> procedure is just allowed to break, with no error handling at all.
> DECLARE @.ErrMsg nvarchar(4000), @.ErrSeverity int
> SELECT @.ErrMsg = ERROR_MESSAGE(), @.ErrSeverity = ERROR_SEVERITY()
> RAISERROR (@.ErrMsg, @.ErrSeverity, 1)
> So, I'm wondering, is it possible to use TRY - CATCH block WITHOUT
> using RAISERROR, but still have the calling app know about it?
> If not, that means we have to rewrite a lot of code, which is not
> desireable.
> Thanks
>