July 15, 2010 at 12:10 pm
doobya (7/15/2010)
First, there is NO "implicit Try..Catch" in C#. If you do NOT put a Try..Catch in the code, it will bubble the exception all the way back to the Framework, and fail the app with an un-handled exception
so you are saying the dot net exception isn't caught by the runtime
but at the same time IS caught by runtime
Let's try this again, restating so that you understand what I am saying... Without the Try..Catch, the APPLICATION does not handle the error, it is left to the Host System, which generates an UNHANDLED exception. Re-Read the post.
which also means there is no way to guarantee resumptive error handling without this (same as csharp)
it is impossible to state that I am wrong
and impossible to say that this is good design
and, due to its uniqueness, impossible to say that it is "obvious"
also anybody harping on about severity levels does not understand what I am saying
What you are calling "resumptive error handling" is not Error Handling, it is a bad design practice used to replace the good coding practice of ensuring that KNOWN error conditions are caught BEFORE they generate an error. "Resumptive error handling" assumes that you can determine the cause and affect a fix in order to resume processing at the point that it left off. If you can do this in the error handling code, than you would be able to pre-screen for the condition causing the error and prevent the need for the Catch ever running. If all you are doing is REPORTING that the error occurred, than Severity level will fix that.
Yes, after 35 years of development in many languages, the last 15 on Object-Oriented and T-SQL, I really DO understand what you are saying. I am telling you that Try..Catch does EXACTLY what it is intended to do, that is catch UNEXPECTED errors and give the developer a chance to recover elegantly before any data damage is done. So, to put it bluntly, YOU ARE WRONG.
July 15, 2010 at 1:11 pm
Rich-403221 (7/15/2010) So, to put it bluntly, YOU ARE WRONG.
Eventually someone spelled it out.
July 15, 2010 at 1:20 pm
Here is what I hear from the OP:
I have a stored procedure written where after each DML statement the value of @@ERROR is evaluated to determine the success or failure of the previous statement. If it failed, code is executed to handle the error in some manner (could be logging the error, etc), then continuing on with additional processing as appropriate.
If this stored procedure is called from another stored procedure outside of a TRY/CATCH block of code, the called stored procedure works as currently coded. However, if you move the call of this stored procedure into a TRY block of a TRY/CATCH pair, the first error encountered in the called stored procedure causes the the execution to exit the called stored procedure and execution is transferred to the CATCH block in the calling stored procedure.
Based on what I have seen in BOL, this is the expected outcome. I still don't see how BOL is ambiguous in this area.
What the OP is saying is that the execution of the stored procedure should be done as an autonomous unit, not affected by the fact that it is contained in a TRY block of a TRY/CATCH pair.
July 15, 2010 at 1:44 pm
Good recap Lynn, that's what I get from the discussion as well.
Can't say as I agree with the OP, I think I would find that very confusing, although I sympathize with having to rewrite so much.
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
July 15, 2010 at 6:12 pm
jcrawf02 (7/15/2010)
Good recap Lynn, that's what I get from the discussion as well.Can't say as I agree with the OP, I think I would find that very confusing, although I sympathize with having to rewrite so much.
This is the best part though ... the guy doesn't even need to re-write anything! If he's happy with how his crusty old procs run, he can just fire them off outside of a TRY...CATCH. It's so incredibly easy not to have these calls within a block.
There is no legitimate complaint. There is nothing ambiguous about the way things work. There is no real inconvenience associated with calling legacy procs.
July 16, 2010 at 3:10 am
Lynn Pettis (7/15/2010)
Here is what I hear from the OP:I have a stored procedure written where after each DML statement the value of @@ERROR is evaluated to determine the success or failure of the previous statement. If it failed, code is executed to handle the error in some manner (could be logging the error, etc), then continuing on with additional processing as appropriate.
If this stored procedure is called from another stored procedure outside of a TRY/CATCH block of code, the called stored procedure works as currently coded. However, if you move the call of this stored procedure into a TRY block of a TRY/CATCH pair, the first error encountered in the called stored procedure causes the the execution to exit the called stored procedure and execution is transferred to the CATCH block in the calling stored procedure.
Based on what I have seen in BOL, this is the expected outcome. I still don't see how BOL is ambiguous in this area.
What the OP is saying is that the execution of the stored procedure should be done as an autonomous unit, not affected by the fact that it is contained in a TRY block of a TRY/CATCH pair.
Yes!
and that should apply to CATCH blocks also ...
... they should never be resumptive under any circumstances
I believe this is either a major misjudgement or an oversight by Microsoft
BOL is ambiguous - nowhere does it state that a CATCH block is resumptive IF it is first in the call stack!
No doubt I could have explained myself better - but at last somebody seems to understand
July 16, 2010 at 3:42 am
doobya (7/16/2010)
Lynn Pettis (7/15/2010)
Here is what I hear from the OP:...Yes!
and that should apply to CATCH blocks also ...
... they should never be resumptive under any circumstances
I believe this is either a major misjudgement or an oversight by Microsoft
BOL is ambiguous - nowhere does it state that a CATCH block is resumptive IF it is first in the call stack!
No doubt I could have explained myself better - but at last somebody seems to understand
Understanding is not agreeing. I'm sure Lynn doesn't agree with you, nor do I.
I believe this is either a major misjudgement or an oversight by Microsoft
I don't think so. It's by design.
I've been coding with Java since 1997 and it's been one of the first oo languages with a strong error handling support and try/catch/finally blocks. I know quite well this subject. TRY/CATCH in T-SQL works exactly as advertised in BOL and exactly as I would have expected based on my java experience.
If it breaks your code, all I can suggest is avoid using it. Please consider you could be intepreting BOL in the wrong way: nobody here seems to agree with you and you should take this fact as a clue...
-- Gianluca Sartori
July 16, 2010 at 4:19 am
Gianluca Sartori (7/16/2010)exactly as I would have expected based on my java experience
Funny, you are pretending to be stupid as a joke?
July 16, 2010 at 4:28 am
doobya (7/16/2010)
Gianluca Sartori (7/16/2010)exactly as I would have expected based on my java experience
Funny, you are pretending to be stupid as a joke?
I don't get this one. Probably I'm missing something.
Can you explain it to me so that I can find it funny too?
I want to believe you're not simply trying to be insulting.
-- Gianluca Sartori
July 16, 2010 at 4:56 am
doobya (7/16/2010)
Gianluca Sartori (7/16/2010)exactly as I would have expected based on my java experience
Funny, you are pretending to be stupid as a joke?
I don't think he is, as try-catch does indeed work in T-SQL exactly as it does in Java and many other languages (except that function calls are used to collect error information rather than an error object being passed as a parameter to the catch block). I don't think you are either - either no pretence is required on your part or you are just trolling (perhaps both, as trolls are usually pretty stupid). So I'm out of this discussion.
Tom
July 16, 2010 at 6:20 am
oh my god
you weren't joking!
given that Java catch blocks are consistently non-resumptive
and T-SQL catch blocks MAY or MAY NOT be resumptive
yes I am calling you stupid
LOL you have even proved my point for me!
[edit] so you can prove you are stupid to yourself I have written this ...
-- first create a proc
create proc dbo.spReadItAndWeep
as
--
begin try
raiserror('raise 16', 16, 1)
end try
begin catch
raiserror('catch start', 0, 1)
raiserror('catch raise 16', 16, 1)
raiserror('if this appears in output you must be stupid', 0, 1)
raiserror('catch end', 0, 1)
end catch
--(end)
-- now run the proc
-- note: there is no existing try block in the call stack
-- note: the output of this includes "if this appears in output you must be stupid"
-- note: which proves the catch block is RESUMPTIVE
-- note: this is NOT behaving like java
-- note: therefore T-SQL TRY CATCH is NOT THE SAME AS JAVA
exec dbo.spReadItAndWeep
-- now run the proc
-- note: we have added a try block in the call stack
-- note: the output does NOT include "if this appears in output you must be stupid"
-- note: this IS behaving like java
begin try
exec dbo.spReadItAndWeep
end try
begin catch
end catch
July 16, 2010 at 7:46 am
You're not doing yourself a favour on this thread.
I think you should acknowledge that there might be things that you cannot change, but can only accept and use, or refuse and avoid.
The important thing is understanding, and it seems to me that you're failing at that.
TRY/CATCH behaviour won't change, no matter how long you insult me or other people that are simply trying to help. Since you appear to be bothered by every attempt to explain things, I'm sure nobody else will keep trying.
Read carefully this thread, it might be your last chance to learn something on this subject.
-- Gianluca Sartori
July 16, 2010 at 8:04 am
Well.
There's nothing wrong with finding T-SQL error handling a bit odd. Some errors terminate the active statement but continue processing the batch, some abort the scope, some abort the batch, others break the connection.
There are also a number of connection-level settings which affect what happens when an error occurs. On top of that we have TRY...CATCH, which if nothing else, behaves a little oddly when XACT_ABORT is ON as Jeff mentioned earlier (see this Connect item for a similar issue.
So, I'm not surprised that some people find TRY...CATCH odd, especially if he or she comes from a background in another programming language. Yes there's no THROW and no FINALLY block. But there you go.
It is also fine to post thoughts about all this on a forum, even if no-one shares your point of view. No-one can say you're wrong about how you feel about something. TRY...CATCH irritates you, and you think the way it works is dumb. Well ok.
What is not cool, however, is the attitude and rudeness. I would strongly encourage a rethink on that.
Paul
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
July 16, 2010 at 8:10 am
July 16, 2010 at 8:49 am
Hey doobya, change your severity level to 17 and run the EXACT SAME PROC and watch what happens.
For everyone else, the main line code raises the error, which then triggers the catch. The catch than raises it's OWN error and completes, also catching the error that IT raised. This continues, looping through 32 TIMES, with the catch executing and then catching it's own error. The ONLY reason that it terminates is that it nests to a 33rd level.
I found that very interesting, in that a level 16 error causes one type of behavior and a level 17 error causes a completely different behavior.
create proc dbo.testError
as
begin try
print 'Begin Try'
raiserror('Try error',16,1)
print 'End Try'
end try
begin catch
print 'Begin Catch'
raiserror('Catch Error',16,1)
print 'End Catch'
end catch
go
Create and run this proc, and then alter to change the severity to 17 and check out the different behavior.
:unsure:
Viewing 15 posts - 61 through 75 (of 81 total)
You must be logged in to reply to this topic. Login to reply