Friday, March 19, 2010

Why you should catch server errors

This morning, I was asked by LinkedIn, where I have an account, to fill out a survey concerning the development tools I use in writing software. What the heck, I thought, sounds interesting, and I clicked on the link. The response I received was an example of such shockingly bad programming that I simply had to share it:



It seems the sever, in the moment I clicked, had a full hard drive (or so I interpret the SQL error: "Not enough storage is available to complete this operation). That's kind of dumb, but shit happens, right? Every programmer and every sys admin makes a mistake eventually, and the result is often a server error. It's a perfectly excusable thing.

What is not at all excusable is allowing a server error to be displayed to a user. Bayasoft builds "smart surveys for smart people", but when their SQL causes an error, they also publish the user_id and password used to connect to their database. Where I work, that screenshot would result in a reprimand if it was generated in any build not running in debug mode. If it was generated by a server connected to the public Internet, I expect someone would be out of a job.

I don't mean to be too hard on whatever programmer out there decided not to put their SQL requests in a try...catch block - as I say, we all make mistakes - but bloody hell, people. You're running a survey database. The entire purpose of your organization is to gather vast amounts of information from people - I think it's not overblown to consider it a major breach of your responsibility to fail to keep that information safe.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.