For animals, pain is a signal that something is wrong and it needs fixing. If pain didn’t exist we’d all be accidentally leaving our hand on the burning gas hob, or on the electric bar fire and wondering about the burning smell long after we’d been injured. We want to know when something isn’t right, and we want to know as quickly and “loudly” as possible.
Writing (programming) a web application is similar. If something isn’t right, if we get the wrong input or something isn’t set up properly, then we’re not going to get a sensible answer out of the system. It’s similar to going into a grocery store, approaching the counter and asking for a hammer… the shop owner is going to tell you straight away that they only sell fruit and veg, not just silently hand you a bag of potatoes and carry on as normal, or walk away and faint. But this is exactly what many web applications and websites do, they receive data they aren’t expecting, or don’t receive data they are expecting, and then attempt to carry on for as long as possibly before (almost) inevitably falling over in a heap or (worse) returning a garbage answer to the user.
This is something hammered into me by a previous development partner: if something unexpected happens, the application should fall over and scream loudly. How the errors is displayed is obviously going to be different depending on the situation: on a development version of the site, a long screed of code and references is appropriate to help to developer fix the problem; and on a production (live) version of the site a user friendly message (“Sorry, the website has just caused an error”, followed by some proposed next steps), and then logging and/or notifying the site maintainers of the problem is the way to go.
WordPress, which I’m using to build a fair few websites for clients, behaves badly in this respect at the moment… I’ve just read that things will improve shortly. I can’t wait.
Leave a Reply