Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Is TRY-CATCH in SQL still a best practice? Expand / Collapse
Author
Message
Posted Tuesday, October 15, 2013 1:11 PM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, December 17, 2013 4:34 PM
Points: 87, 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)
Post #1504928
Posted Tuesday, October 15, 2013 1:18 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 9:38 AM
Points: 13,093, Visits: 11,925
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 Moden's 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)
Post #1504930
Posted Tuesday, October 15, 2013 1:24 PM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 7:43 AM
Points: 13,275, Visits: 10,152
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?

Member of LinkedIn. My blog at LessThanDot.

MCSA SQL Server 2012 - MCSE Business Intelligence
Post #1504935
Posted Tuesday, October 15, 2013 1:26 PM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 3:14 AM
Points: 42,460, Visits: 35,520
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 2008, MVP
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

Post #1504937
Posted Tuesday, October 15, 2013 1:27 PM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, December 17, 2013 4:34 PM
Points: 87, 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...
Post #1504939
Posted Tuesday, October 15, 2013 1:29 PM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, December 17, 2013 4:34 PM
Points: 87, 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...
Post #1504941
Posted Tuesday, October 15, 2013 1:31 PM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 3:14 AM
Points: 42,460, Visits: 35,520
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 2008, MVP
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

Post #1504944
Posted Tuesday, October 15, 2013 2:22 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 9:39 AM
Points: 7,038, Visits: 12,953
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
Post #1504969
Posted Tuesday, October 15, 2013 3:07 PM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Tuesday, December 17, 2013 4:34 PM
Points: 87, Visits: 124
Thank you everyone for your feedback!

-LJ
Post #1504992
Posted Tuesday, October 15, 2013 6:33 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 7:48 AM
Points: 36,759, Visits: 31,214
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.

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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1505036
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse