I've often told my developers that throwing errors is a good thing. You want to know about errors when they occur or they will never get fixed. Obviously, that does not mean you should not handle errors, but a far worse situation is when something looks right. As someone once said, "It is not what you know that gets you in trouble; it is what you think you know".
Today I ran into something that is close to voodoo. I was reviewing some Classic ASP code (bleh, don't ask) that was making a SQL call. In this case, the user was populating a list of checkboxes with a guid ID value and a name and then taking the result list and passing it directly to SQL hoping that it would work like an IN clause. However, their code came out as something like:
"...Where ID = '{958BE980-9CA8-42C1-A4FA-998200CE2BAB}, {DD0A61EF-A5A0-45CA-B36F-998200CE2BAB}'"
Now, clearly this should not work as the string cannot be cast into a uniqueidentifier. Yet it does. It runs and returns values where the ID is equal to the first guid. That IMO is a bug in SQL Server. It should throw an error telling me that the string cannot be cast into a uniqueidentifier. The worst part is that developers will generally miss this error because something does come back and they do not get an error. If they don't get all the results they expect, they would likely chalk it up to missing data.
Subscribe