Eliminate Lazy Error Handling

Here is an error I received the other day…

“Authentication Failure”

Here is another…

“Format of the initialization string does not conform to specification starting at index 0, without any typo in connectionString”

And finally my favourite…

“The entity cannot be updated because it is read-only.”

They are all from different applications and implementations and have been my life for the past two days as I tried to figure them out and wasted an insane amount of time trying to figure out what they related to and what I had to do to resolve them.

Here were the resolutions (in order)…

“Multi-Factor authentication is not supported here.”

“You need to enter the string in a special way, but we won’t tell you how.”

“It’s not that the entity was read-only, it’s that a function was trying to modify it while it was being made read-write.”

We have full stack error logs available to us and we know “when, where and how” something is going wrong when an error throws up – in error handling, context and next steps are key.  If you are building an error message consider doing the following for your users.

  1. All Error messages should be referenced on a webpage on your site that is easily updated and groups errors and warnings and list them by number.  This way as time evolves or issues become deprecated, you can update them BUT the user always has somewhere to go to get the latest and greatest.
  2. Use plain language to describe the error, i.e., in the example above, the Authentication Failure would be a good grouping, but not a good description.
  3. The description, yes this is the kicker, what you think it is when it happens, you ran through it in development, so you have a good idea what it might be – “Authentication Failure – if you have MFA or overtly complex passwords or passwords that have expired, you might get this message” – now the user has a direction to go before digging in.
  4. Dump the Stack, maybe this is optional, but dump it, not for the user, but for you to reference later when you are trying to diagnose.  Seriously, if you were presented with an error from a client that said – “Authentication Failure” where would you really start?

I know, I know, Error Handling is the last thing on our minds when it comes to cranking out shiny new code, but it’s also the first thing that users see when something goes sideways and it can also be the reason they turf your product when because of it, they have wasted an insane amount of time that is no longer worth the expense.

And if you don’t want to do it for your users, do it for your team, because they are the next ones that are going to be debugging your code trying to figure out what just went wrong.

Post A Reply

%d bloggers like this: