If anybody is writing .Net code that in the future I am going to have to find an error in, can they refrain from doing things like this:
try
{
...
}
catch (Exception e)
{
throw new ApplicationException("ConnectionException has occured: " + e.Message);
}
finally
{
....
}
The particular application I was working on this morning used this particular gem pretty well everywhere. The problem was that we were getting an unhandled ApplicationException – the re-thrown error wasn’t being trapped anywhere else – and since the above bit of code throws away the stack trace from the original exception, we were left trying to guess where the error was actually occurring.
The irony is that the code was written by a contractor who apparently had a pretty stellar CV, and amongst other things quite regularly criticised other people on the team over their apparent bad programming. His contract wasn’t renewed, and since then we’ve been discovering quite how bad his programming really is – a definite lesson that however good a contractor appears on paper, you need to properly monitor what they are doing.
Other gems in this particular application include every SQL statement being built by concatenating strings together – and no, not a StringBuilder in sight. Using ToString() to do the conversions where needed, including quite a few points where he calls ToString() on a string – indeed a large amount of the data is just held as strings anyway, only being converted back to integers or dates in the stored procedures when SQLServer needs the right types. He had also written his own replace function, which he was using instead of String.Replace although it was functionally identical, and that wasn’t the only place he’d hand crafted code that replicated functionality in the framework. The code was littered with other common errors, for example it’s a good job we don’t have anybody with the surname O’Reilly…
Since we were fixing a specific problem, much as I would like to, there wasn’t the opportunity to fix all of these other problems, essentially we have to wait until something else breaks, and fix it then. And the source of the problem today? A stored procedure that was trying to convert one of the multitude of strings being passed through back to an integer in order to use it. That conversion was failing and throwing an error that was passed back to the client and helpfully chucked away by the error handling code I started with – the only clue we had as to where it was going wrong was that the error message seemed like it was coming from SQLServer.
Possibly Related Posts- The Doctor's Daughter After all the speculation as to who the titular daughter was going to turn out to be, what we in fact got in The Doctor's Daughter was a new character - an extension of the continuity rather than an attempt to weave a story within the established history of the......
- Think You Were Lost Before? You Are Now... I'm getting this whole deja-vu feeling - I think perhaps much the same feeling I had when we'd watched the season one finale of Lost. Having watched the finale of season two, Beth's first words were 'I hate them!', them of course being messieurs Lieber, Lindelof and Abrams who are......
- Visual Studio 2005 Useless Error Message It seemed like a simple task - build a user control to search a database by date, so yesterday afternoon I set about putting the form together, using the Developer Express .NET controls. The form all seemed to be working fine, until I tried to reopen it in Visual Studio......
- Fly Tipping by J R Hartley Every so often I catch an edition of Rogue Traders, a BBC consumer show that uses secret filming to trap unscrupulous tradesmen. In the past it has been everything from solar panel salesmen to gardeners, and is usually a catalogue of dodgy selling techniques, and shoddy workmanship. Tonight, the subject......
- Never Upset a Lawyer Years ago, a friend of mine was called as a witness for the prosecution in a local magistrates court. Although the charges were relatively minor, the defendant was the son of the agent of a rather senior politician of the time. The evidence against the defendant was pretty conclusive, however......
Follow me on Twitter 
If I didn’t know better I’d say he’d come to work for us!
Eric Lippert wrote something interesting about exceptions this week at http://blogs.msdn.com/ericlippert/archive/2008/09/10/vexing-exceptions.aspx.