Bad Programming: How not to use try/catch blocks

I just stumbled across the following SQL 2005 code:

	BEGIN TRY
		UPDATE [tabProgramSite]
		SET
			[Name] = @ProgramSiteName
		WHERE [ProgramSiteID] = @ProgramSiteId
	END TRY
	BEGIN CATCH
	END CATCH

Nothing like catching an error… and doing nothing about it. I hope the user experience isn’t as robust.

Popularity: 14% [?]

Posted 12 June 2008
Tags: bad programming, SQL ‡ Category: Technology
Post a comment ‡ Trackback URL
All Posts ‡ All Comments

Society loses the value of objects unnecessarily destroyed.

-- Frédéric Bastiat, Economist

Lucas wrote:
Sounds familiar! I recently went through the source code of a production application adding (at least) some logging code into hundreds (well, maybe just dozens) of empty catches.

It was VERY frustrating when the client reported a problem and sent us log files, and the logs didn’t have the slightest hint of what the problem was. Here we say the application “eats” the exceptions. om nom nom nom …

The fact that it was written in VB was also frustrating, but that’s just me
Posted 12 Jun 2008 at 2:47 pm ¶
brian wrote:
VB… the language that should not be.
Posted 12 Jun 2008 at 3:26 pm ¶
harborpirate wrote:
Even worse is that in many cases you take a performance hit (though slight) for adding an exception handling routine. This is a great trade-off when you get a more robust application out of it since the difference is extremely small. When you have an empty catch you’re screwing yourself twice. Errors won’t bubble out to the calling software so you won’t know what happened AND your code will run ever so slightly slower.
Posted 27 Jun 2008 at 5:10 pm ¶
brian wrote:
Having a try/catch block without anything in the catch is like fishing and never looking at what’s on the hook.
Posted 02 Jul 2008 at 9:43 am ¶