Error Tolerance In Software

Every software developer knows that an application may trigger lots of errors. Many factors can cause it — bad configuration, invalid source data, inexperienced users, lack of knowledge, etc. However, an application may tolerate some errors and do not tolerate others. So, where is the border which separates them?

Two Opposite Approaches

There are two opposite approaches in error tolerance and the way a customer may see it.

The first approach is not to tolerate errors at all. Application is going to reject all requests which contain invalid data and send a customer list of errors. There is no auto-correction; there is no possibility to skip invalid data. The data must be entirely correct, with no exceptions.

Another alternative approach allows a customer to send invalid data or perform an action in the wrong way. The application is going to automatically correct data when it is possible, and skip invalid data if it can not be processed. A customer is going to receive notification about the corrected and omitted data.

Rely On Business Cases

Although the second approach is more user friendly and provides a better user experience, both these approaches have their uses. Business cases have to define which of these approaches is better in every specific case.

The strict approach has its uses if there are security checks, data is atomic, or there are many dependencies in entered data. It is generally easier to implement, so early releases often use this approach.

The flexible approach is better when the application works with less sensitive data, and minor errors can be tolerated. This tolerance often requires lots of experience and statistics to understand when and how it has to work. That's why only later stages of application development make use of this approach.

However, in the end, it is up to customers to decide which approach is better for them in every situation. So, how to adapt the application to that?

Ask Customers

The most apparent solution is to give a customer a choice between these two options. For example, a customer may enable a flexible approach in his profile. Alternatively, he can specify which of errors from the strict approach he wants to see, and which can be skipped. Such configuration options introduce adaptability to customer's use cases to give him the best user experience.

Another way to do it is to give the possibility to write feedback and describe what bothers a customer on every page. This information can be a hint for future improvements both in error tolerance and user experience. Besides that, a customer can see that he can affect application behavior by providing feedback and wait for improvements. Alternatively, an application may ask the customer to participate in a survey to get a customer's overall impression and improve the described areas.

One way or another, the customer has to express his opinion about error tolerance, user experience, and overall application behavior. Only then the application administrator can be sure that the customer can fulfill his needs and be satisfied with the functionality of the application.