Design for errors

I’ve been recently working on the frontend of a web application, basically I had to add a tab to a tab panel and do some stuff there. One of the requirements was, of course, “be careful not to break the other tabs because they’ve been in production for some months now and the user is happy with those”.

So I got to work and when I had the basic skeleton of my new tab I opened the browser to test it. One of the first thing I’ve tried was randomly clicking on all the tabs to see if my tab would correctly reload the interface without glitches. But in doing so I noticed that the other tabs where showing some problems, so I thought I had broken something in the old code, although I barely touched it. I switched to the test environment (which didn’t have any of my changes) and did the same thing, which got me basically the same results.

So I opened the DevTools console to see what was going on, reloaded the page and saw a stream of errors getting thrown by the javascript code that defined and set the behaviour of the tab panel, probably since it first went into production. The errors caused some anomalies in subsequent user’s actions, such as incorrect loading of the page or undefined objects if the user kept clicking on the tabs. Keep in mind that “the user is happy with it”, that is, with the current behaviour of the panel: which means that the errors were well-concealed and the erratic frontend behaviour was not very common.

Now, while it is true that the average user would never click like a madman back and forth on the tabs, like I was doing, and would probably reload the page in case something totally unexpected happened, I believe it’s better to design for errors, that is: make the errors and the exceptions as visible as possible, in order to catch them pretty soon in the development or testing phase.

How many times do we see code like this:

try {
  // do something
} catch (Exception e) {
  // do absolutely nothing, like that's never happened, just move on with the rest of the code
}

It’s fast, it’s easy, it makes the app look amazingly stable: everybody’s happy, right? But no: it’s a sloppy programming habit, it makes the errors invisible even though they are still happening and they will come up, sooner or later (usually much, much later, when something big happens).

So what’s your choice: try-catch everything and wait until it’s possibly too late to fix an error or make it come up as soon as it happens (even if the user is testing) so you can fix it right away, once and for all?

Feel free to drop me a line on twitter.