Mishandling errors

For the past 3 years, I’ve been working full-time as a software engineer.  This has been a substantial, if not calculated, change for me.  I’d been an hardware engineer for longer than I care to think about.

Perhaps the biggest, while subtlest difference between the two career paths that I didn’t see coming is this: determinism.  I simply love the relative absolute nature of software.  I’m sure some might argue me on that one.  But, you get my point.  For the most, the outputs of any software project can be clearly predicted; the inputs can be nicely quantized, packaged, and displayed in automated fashions.

I love going to work.

Even on the tedious days of making error handling code, it’s still all fun.  Exception handling is one of those topics that is grossly underestimated.  It’s hard work, it’s time-consuming (and no one appreciates that investment), and it’s rewards are always deferred.

I’m reminded of all of those points when I witness — virtually everywhere in “real life” —  examples of horrendous error handling.

Case in point

While attempting to post a mobile deposit to my bank account, I got an error.  The transaction didn’t post, for whatever reason.  This was on my Android phone, from which I’ve made dozens of successful deposits in the past to the same bank with the same app.

Fair enough, errors happen.

But the error message I was greeted with was the following:

Not much help there, huh?

The point of error handling is twofold:

  1. Assist the user in resolving the problem
  2. Provide the developer with the conditions prior to the error from which to find a solution to the problem

From the above screenshot, there’s next to nothing for the bank’s engineering team to go on.  The tech support tips I got amounted to, “Have you tried uninstalling?”

It’s no wonder that most people’s relationship with software is terrible.  And I’m a software engineer (now)!

Leave a Reply