January 20, 2010 at 7:15 am
It was fairly easy to see the concept which was being put across here regarding try/catch blocks - not exactly a new one for most developers these days I should imagine. But if I'd posed that question in an interview and the candidate had given the answer given as correct I would not have marked it as correct.
The answer given as correct implies that the text of the error message was somehow inserted into the table and then returned as part of the result set - completely wrong.
January 20, 2010 at 7:28 am
Lynn Pettis (1/20/2010)
To all those who are expecting PRECISELY CORRECT ANSWERS, how about putting yourself out there and submit some questions. The answers may not have been precise, but I don't feel that it really took that much away from the question. What was important was seeing that using the TRY/CATCH kept the while loop from being aborted, allowing you to control the processing within SQL itself.
Here I was going to complain about the correct answer not being one of the options but I was beaten to it several times over!
The problem with the correct answer not being one of the options is that it confuses junior and intermediate level folks (I would consider myself intermediate as there is a ton about SQL Server that I don't know.)
By the way, is it just me, or is your signature getting longer? :hehe:
Kev -=Conan The Canadian=-
@ConanTheCdn
January 20, 2010 at 7:36 am
Lynn Pettis (1/20/2010)
... What was important was seeing that using the TRY/CATCH kept the while loop from being aborted, allowing you to control the processing ...
I totally agree. This was a great example of how to loop and do conditional processing with error handling and without a cursor.
Excellent question, I made some edits and comments and have saved it for future reference.
declare @i int, @j-2 int
set @i = 1
create table #temp (id int)
while (@i<=5)
begin -- while loop
begin try -- trap errors
begin transaction
if (@i = 3)
set @j-2 = @i/0
insert into #temp values (@i) -- insert values when there are no errors
print '@i = [' + Convert(varChar(8), @i) + ']'
commit transaction
end try
begin catch -- handle errors
rollback transaction
print 'An error was caught when @i = [' + Convert(varChar(8), @i) + ']';
end catch
set @i = @i + 1
end -- while loop
select * from #temp
drop table #temp
January 20, 2010 at 7:39 am
The original choices do not contain correct answers. Please verify the Q/A before it is published.
Imagine you take a GRE special topic test that involes world wide thousands of thousands people on the same day, and in the middle you found there is a question there has no correct answer. We have to guess what it was asking. This is the test that determine your fate.
Try-catch was invented 20 years ago when I coded C++, it is nice to see people starts understanding it in SQL community.
Jason
http://dbace.us
😛
January 20, 2010 at 7:49 am
nomlad (1/20/2010)
It was fairly easy to see the concept which was being put across here regarding try/catch blocks - not exactly a new one for most developers these days I should imagine. But if I'd posed that question in an interview and the candidate had given the answer given as correct I would not have marked it as correct.The answer given as correct implies that the text of the error message was somehow inserted into the table and then returned as part of the result set - completely wrong.
Is it wrong? Look a little closer, did the individual understand how the code itself worked? Maybe the output was formated wrong, but the content correct. You can always work with someone to make sure they have better understanding of how the output would actually be presented, but they would have at least demonstrated an understanding of the concepts. In the case of an interview, I'd have to give partial credit at least.
January 20, 2010 at 7:54 am
I'm sure most of you complaining would have preferred to have seen this as the code:
declare @i int, @j-2 int
set @i = 1
while (@i<=5)
begin
begin try
begin transaction
if (@i = 3)
set @j-2 = @i/0
print @i
commit transaction
end try
begin catch
rollback transaction
print 'this is an exception';
end catch
set @i = @i + 1
end
This way, the answers are precise. This is what I looked for at first based on the answers provided. But not seeing this as the code did not change which answer I chose.
January 20, 2010 at 7:55 am
OK, partial credit it is then 🙂
January 20, 2010 at 7:57 am
I had a bit of problem as well with "invalid object name #temp" AT FIRST - wierd.
I changed it to #ttt and it worked right away. Dropped #ttt and changed back to #temp and it worked away. Set no count on - doesn't hurt either and probably should have been included in the teaser. Changing output to text as opposed to grids (Ctrl +T for text out and Ctrl + D for grid output) gave me this output:
this is an exception
id
-----------
1
2
4
5
And here is my formatted code snippet with tab formatting - btw I read in a previous thread that "this code snippet is what most us would have liked to have seen" - I agree:
drop table #temp
create table #temp (id int)
declare @i int, @j-2 int
set @i = 1
while (@i<=5)
begin
begin try
begin transaction
if (@i = 3)
set @j-2 = @i/0
insert into #temp values (@i)
commit transaction
end try
begin catch
print 'this is an exception';
rollback transaction
end catch
set @i = @i + 1
end
select * from #temp
So what is the SSC correct answer to this problem? Although div by zero is certainly going to throw and exception and the concept of this teaser is exception handling in TSQL - has there been a consensus as to what the correct answer is?
-Mike
January 20, 2010 at 7:58 am
The problem with the correct answer not being one of the options is that it confuses junior and intermediate level folks (I would consider myself intermediate as there is a ton about SQL Server that I don't know.)
This right here.
When I saw none of the possible answers matched what I expected I assumed my understanding of how things works was wrong. I knew 3 could not be in the answer. I also knew you could not get a string out of an int field. That left me with only one other choice.
The question was good. The selection of answers was abysmal.
January 20, 2010 at 8:00 am
The original choices do not contain correct answers..Please Dont Post like this questions..yesterday also same...question is correct but answer is not in the list...! Again Today Same...!
January 20, 2010 at 8:05 am
jswong05 (1/20/2010)
The original choices do not contain correct answers. Please verify the Q/A before it is published.Imagine you take a GRE special topic test that involes world wide thousands of thousands people on the same day, and in the middle you found there is a question there has no correct answer. We have to guess what it was asking. This is the test that determine your fate.
Try-catch was invented 20 years ago when I coded C++, it is nice to see people starts understanding it in SQL community.
I'm really sorry if you think the QotD and GRE are even remotely equivalent. I would definately expect the questions on the GRE to heavily fetted as the GRE is used to determine acceptance to many Graduate programs. The QotD is nothing as serious as that. To expect that is, to me, unrealistic.
January 20, 2010 at 8:06 am
Raj The King (1/20/2010)
The original choices do not contain correct answers..Please Dont Post like this questions..yesterday also same...question is correct but answer is not in the list...! Again Today Same...!
Okay, would you please submit a QotD?
January 20, 2010 at 8:24 am
I certainly dont' want to get into a criticizing of the QoTD. I have learned much from them. But being what I consider to be a SQL noob/beginner, I look to them sometimes for education. I feel that I'm becoming fairly proficient at reading code so when I looked over this one, I immediately recognized that the exception error message was a PRINT statement and not an insert. Therefore wouldn't have been in the SELECT results. Imagine my surprise when I got it wrong.
Most of the time, if I get it wrong, I just accept it, read up on why I got it wrong and move on. Sometimes though, I think it's just a dumb mistake and don't bother to look it up (it's why I struggled with SAT's). Questions like this where I'm pretty confident I know the answer and then see that I'm wrong frustrate me as someone who's still learning. When I think I have a concept down, the answer tells me I don't, I get befuddled and don't want to continue. Glad I came in here for validation today though.
As for submitting my own QoTD as another poster suggests, not a chance. I couldn't come up with anything challenging enough for most of the folks here. I'd get laughed off the boards I'm sure. I'm just not wired that way. But when I come here looking to bolster my education and get further confused, that's not good practice. I applaud those that do post questions though, way to get out there and be bold. But are the questions and answers verified by SSC.com folks prior to posting live?
I'll get down off the soapbox now. Thanks for reading.
The distance between genius and insanity is measured only by success.
January 20, 2010 at 8:48 am
Brnbngls (1/20/2010)
I certainly dont' want to get into a criticizing of the QoTD. I have learned much from them. But being what I consider to be a SQL noob/beginner, I look to them sometimes for education. I feel that I'm becoming fairly proficient at reading code so when I looked over this one, I immediately recognized that the exception error message was a PRINT statement and not an insert. Therefore wouldn't have been in the SELECT results. Imagine my surprise when I got it wrong.Most of the time, if I get it wrong, I just accept it, read up on why I got it wrong and move on. Sometimes though, I think it's just a dumb mistake and don't bother to look it up (it's why I struggled with SAT's). Questions like this where I'm pretty confident I know the answer and then see that I'm wrong frustrate me as someone who's still learning. When I think I have a concept down, the answer tells me I don't, I get befuddled and don't want to continue. Glad I came in here for validation today though.
As for submitting my own QoTD as another poster suggests, not a chance. I couldn't come up with anything challenging enough for most of the folks here. I'd get laughed off the boards I'm sure. I'm just not wired that way. But when I come here looking to bolster my education and get further confused, that's not good practice. I applaud those that do post questions though, way to get out there and be bold. But are the questions and answers verified by SSC.com folks prior to posting live?
I'll get down off the soapbox now. Thanks for reading.
It isn't just the QotD that you can learn from, but also the discussion that may follow (as long as you ignore the complaints).
Does SSC vet the questions, to a point, but not nearly as well as some people would like to see. Of all the questions I have answered, I think I only really had a serious complaint about one or two. Yes, there are issues with some of the questions, but if you look closer at the concept that the question is trying to address, and less on the question and answers themself, I think you will learn something.
Take today's question. Based on the answers, you'd have expected there to be PRINT statements in the question but there wasn't. If you understand the concept of the TRY/CATCH, and that the divide by zero would be caught and handled in the CATCH part of the code, there really was only one answer that made sense, and it happened to be the only one with the message from the PRING statment in the CATCH block.
January 20, 2010 at 8:50 am
Lynn Pettis (1/20/2010)
To all those who are expecting PRECISELY CORRECT ANSWERS, how about putting yourself out there and submit some questions. The answers may not have been precise, but I don't feel that it really took that much away from the question. What was important was seeing that using the TRY/CATCH kept the while loop from being aborted, allowing you to control the processing within SQL itself.
I agree on both points - the imprecision detracted little from the question, and if someone wants better questions, they can always submit one of their own.
In fact, with slight rewording, focusing on the precise output format is almost irrelevant:
Instead of "Try to predict the output..." the question might have read: "Which choice best matches the expected results of the code?" (I think the term "results" covers both query messages and query output.)
I can certainly see why someone would point out that the output given did not exactly match the results in the choices. Precision is to be desired when working with data. But it really comes down to whether you thought "this is an exception" would print as well as how many of the digits would appear in the final output. And to that end, the range of options seemed clear to me. If there had been another choice with the phrase "this is an exception" listed somewhere else in the output, then the objections would be stronger, IMHO.
-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html
Viewing 15 posts - 16 through 30 (of 54 total)
You must be logged in to reply to this topic. Login to reply