SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Is TRY-CATCH in SQL still a best practice?


Is TRY-CATCH in SQL still a best practice?

Author
Message
Larry Johnson-473989
Larry Johnson-473989
SSC-Enthusiastic
SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)

Group: General Forum Members
Points: 127 Visits: 124
I overheard our DBA today (2013-10-17) telling a junior developer to NEVER use a TRY-CATCH block in stored procedures. He told her that it is a very inefficient way of creating a transaction and should not be used. He said it was only still available for "backward compatibility." Instead, he suggested she put a BEGIN TRANSACTION and COMMIT or ROLLBACK TRANSACTION around anything that would do an insert or update.

To my knowledge, TRY-CATCH was introduced in SQL 2005. I've been using it regularly as a best practice since about 2007, and this is the first time I've ever heard anyone say it should not be used.

Any opinions here? Is a TRY-CATCH block still a valid practice today?

(Part of the reason I'm obsessing over this is because he is pretty full of himself and also made the statement, "Trust me, I've been doing this for 10 years," to support his argument. That kind of statement drives me nuts.)

Thanks!

edit: took out the stupid and invalid "END TRANSACTION" statement. (LJ)
Sean Lange
Sean Lange
SSC Guru
SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)

Group: General Forum Members
Points: 61727 Visits: 17954
Larry Johnson-473989 (10/15/2013)
I overheard our DBA today (2013-10-17) telling a junior developer to NEVER use a TRY-CATCH block in stored procedures. He told her that it is a very inefficient way of creating a transaction and should not be used. He said it was only still available for "backward compatibility." Instead, he suggested she put a BEGIN TRANSACTION and END TRANSACTION around anything that would do an insert or update.

To my knowledge, TRY-CATCH was introduced in SQL 2005. I've been using it regularly as a best practice since about 2007, and this is the first time I've ever heard anyone say it should not be used.

Any opinions here? Is a TRY-CATCH block still a valid practice today?

(Part of the reason I'm obsessing over this is because he is pretty full of himself and also made the statement, "Trust me, I've been doing this for 10 years," to support his argument. That kind of statement drives me nuts.)

Thanks!


If you got your quote correct that person is moron. TRY-CATCH is not used to create transactions. It is used as a way to handle errors. It is not deprecated so the discussion about it being for backwards compatibility is completely ridiculous.

Here is the page in BOL. http://technet.microsoft.com/en-us/library/ms175976.aspx

Next I am guessing this person will tell them to use "nested transactions" when there are a series of inserts that all need to work.

_______________________________________________________________

Need help? Help us help you.

Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

Need to split a string? Try Jeff Modens splitter.

Cross Tabs and Pivots, Part 1 – Converting Rows to Columns
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs
Understanding and Using APPLY (Part 1)
Understanding and Using APPLY (Part 2)
Koen Verbeeck
Koen Verbeeck
SSC Guru
SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)SSC Guru (61K reputation)

Group: General Forum Members
Points: 61563 Visits: 13297
Larry Johnson-473989 (10/15/2013)
I overheard our DBA today (2013-10-17) telling a junior developer to NEVER use a TRY-CATCH block in stored procedures. He told her that it is a very inefficient way of creating a transaction and should not be used. He said it was only still available for "backward compatibility." Instead, he suggested she put a BEGIN TRANSACTION and END TRANSACTION around anything that would do an insert or update.

To my knowledge, TRY-CATCH was introduced in SQL 2005. I've been using it regularly as a best practice since about 2007, and this is the first time I've ever heard anyone say it should not be used.

Any opinions here? Is a TRY-CATCH block still a valid practice today?

(Part of the reason I'm obsessing over this is because he is pretty full of himself and also made the statement, "Trust me, I've been doing this for 10 years," to support his argument. That kind of statement drives me nuts.)

Thanks!


Wut?
Keep that man away from databases!
Next he'll tell you to rewrite your code to use cursors.


How to post forum questions.
Need an answer? No, you need a question.
What’s the deal with Excel & SSIS?
My blog at SQLKover.

MCSE Business Intelligence - Microsoft Data Platform MVP
GilaMonster
GilaMonster
SSC Guru
SSC Guru (221K reputation)SSC Guru (221K reputation)SSC Guru (221K reputation)SSC Guru (221K reputation)SSC Guru (221K reputation)SSC Guru (221K reputation)SSC Guru (221K reputation)SSC Guru (221K reputation)

Group: General Forum Members
Points: 221079 Visits: 46279
Larry Johnson-473989 (10/15/2013)
I overheard our DBA today (2013-10-17) telling a junior developer to NEVER use a TRY-CATCH block in stored procedures. He told her that it is a very inefficient way of creating a transaction and should not be used. He said it was only still available for "backward compatibility." Instead, he suggested she put a BEGIN TRANSACTION and END TRANSACTION around anything that would do an insert or update.


Wow, that's ... interesting.

Try ... catch doesn't create a transaction at all (trivial to prove) and hence begin transaction cannot be considered a credible alternative to try..catch

Try .. catch is most certainly not deprecated (ie included only for backward compatibility) and it is in fact newer than begin transcation.

END TRANSACTION is not valid T-SQL.

BEGIN TRANSACTION
DELETE FROM a
END TRANSACTION



Msg 156, Level 15, State 1, Line 4
Incorrect syntax near the keyword 'TRANSACTION'.


Try.. Catch is for error handling, much like in front end languages. It does not create, roll back or commit transactions.
BEGIN TRANSACTION... ROLLBACK/COMMIT TRANSACTION is for transaction management, for making a group of data modifications execute atomically. It does not do error handling.

In short, he might as well have said 'Trains are outdated, don't use them. I recommend using a microwave oven instead"

Perhaps of interest: http://sqlinthewild.co.za/index.php/2011/05/17/on-transactions-errors-and-rollbacks/

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass


Larry Johnson-473989
Larry Johnson-473989
SSC-Enthusiastic
SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)

Group: General Forum Members
Points: 127 Visits: 124
Thanks, Sean. I also looked through that article prior to posting my question, and I couldn't find anything to support his assertions. I thought: What am I missing here?

So now I need to come up with a strategy to convince him otherwise...
Larry Johnson-473989
Larry Johnson-473989
SSC-Enthusiastic
SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)

Group: General Forum Members
Points: 127 Visits: 124
@Gail: Oops, my bad on the "END TRANSACTION". I was just so pissed that he was bad-mouthing me behind my back to the junior developer (because I'm the one who told her to use transactions) that I was typing before thinking...
GilaMonster
GilaMonster
SSC Guru
SSC Guru (221K reputation)SSC Guru (221K reputation)SSC Guru (221K reputation)SSC Guru (221K reputation)SSC Guru (221K reputation)SSC Guru (221K reputation)SSC Guru (221K reputation)SSC Guru (221K reputation)

Group: General Forum Members
Points: 221079 Visits: 46279
One retort. If he insists that TRY..CATCH is an 'inefficient way of starting a transaction', then you could start by proving to him that it doesn't start a transaction at all.

Maybe offer him that blog post? Though if he's as set in his ways as you make out, he may refuse to read someone else's 'ignorant opinion' (as I've had my work described before :-) )

Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass


LutzM
LutzM
SSC-Insane
SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)SSC-Insane (23K reputation)

Group: General Forum Members
Points: 23383 Visits: 13559
Well, your DBA is absolutely right "that it (a TRY-CATCH block) is a very inefficient way of creating a transaction". :-)
I also agree, that it therefore should not be used for transactional mananagement.

But for totally different reasons than he does, as already explained.

Maybe you can get him into a discussion by agree to a part of his statement first (to polish his halo) followed by "the bad news"...
Another option would be to ask him for a more detailed explanation and some sample code so you can "widen your view" and learn from his "10 year experience".



Lutz
A pessimist is an optimist with experience.

How to get fast answers to your question
How to post performance related questions
Links for Tally Table , Cross Tabs and Dynamic Cross Tabs , Delimited Split Function
Larry Johnson-473989
Larry Johnson-473989
SSC-Enthusiastic
SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)SSC-Enthusiastic (127 reputation)

Group: General Forum Members
Points: 127 Visits: 124
Thank you everyone for your feedback!

-LJ
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (212K reputation)SSC Guru (212K reputation)SSC Guru (212K reputation)SSC Guru (212K reputation)SSC Guru (212K reputation)SSC Guru (212K reputation)SSC Guru (212K reputation)SSC Guru (212K reputation)

Group: General Forum Members
Points: 212115 Visits: 41977
Sean Lange (10/15/2013)
If you got your quote correct that person is moron.


Heh... if the quote is correct, then that "DBA" is more off than on, so stop insulting morons. He's clearly a moroff. :-D

The one thing that I do agree with is...
... if there are no special error messages required and
... if all you're going to do in the CATCH block is rethrow the same error and
... if you don't need redirection of special handling on an error
... then there's usually no need for Try/Catch blocks in a stored procedure. Let SQL Server do what it was designed to do. If you need multiple commands in a stored procedure to act as an "all or nothing" unit, the using explicit transactions with SET XACT_ABORT ON is usually enough for a lot of people.

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search