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.

4 thoughts on “Bad Programming: How not to use try/catch blocks”

  • 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 🙂

  • harborpirate says:

    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.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>