Anticipating Unanticipated Errors

Great article over at Cocoa with Love on structuring Swiftily elegant error handling:

Presenting unanticipated errors to users

The best approach for presenting error conditions to the user is to integrate feedback into the user interface about the condition that the error indicates. This could be changing an icon, colors, adding status text or otherwise changing the state of a user interface element.

This “best approach” requires that we understand the error condition and plan for it in advance.

What if we’re still implementing the app and haven’t had time to exhaustively discover possible error conditions and plan for them? What about technically possible error conditions that we cannot trigger in our own testing making planning impractical? What about error conditions that should never occur if everything is well behaved but are still semantically possible?

We need a base level tier of error handling and reporting to the user. This base level must be very low overhead (so we can add it use it without much thought during development) and while it must report an error to the user, it is primarily intended to gather diagnostic information so the source of the error condition can be understood and facilitate fixes and other maintenance…

The idea is that we end up with runtime-presented information along the lines of

error_dialog2.png

where “Copy Details” provides a full stack trace. Sound interesting? Read the whole thing! And grab the code from the CwlUtils repo on Github!

While we’re on the topic, assertions are an excellent way to anticipate those unanticipated errors; can you name the five types of Swift assertions and enumerate the differences between them? If not, check out (h/t Swift Sandbox):

Andy Bargh’s Swift Assertions

… Not only do assertions allows us to articulate our critical assumptions within code they also help us to design code that ensures the conditions leading up to those assertions are highly unlikely, whilst simultaneously providing us with flexibility and control over when those assertions are enforced.

In some cases, developers advocate that you should only use assertions when developing and debugging, whilst others recommend leaving them in in production as well. My personal preferences lean toward the latter of these two camps. My view is that although triggering an assertion failure is not good, and is definitely not a great experience for end users, I would far rather know about the failures and attempt to fix them, either though additional handling and checking in our code or redesigning things so ensure that the situations leading up to the assert failures don’t occur. For me I feel that this is a better approach to improving the quality of my applications.

We’re totally on board with that. And you should be too!

Alex | May 10, 2016

Leave a Reply