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: 13% [?]
Related posts:
- Bad programming examples (part 1 of x)
- Stop the “restart” popup from Windows Update
- The Spark View Engine (and a brief history of web programming)
- Can’t install TFS, or the .Net Framework, or almost anything? Check your security policies!
- Scripting the deletion of objects in a SQL database (second version)
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
VB… the language that should not be.
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.
Having a try/catch block without anything in the catch is like fishing and never looking at what’s on the hook.