It has long been considered a good practice that software be loose with its inputs and strict with its outputs. This ensures your software can work with a wide variety of third party systems, tolerating their output peculiarities and producing clean data that may be widely accepted. The web and the wide variety of truly terrible HTML that may be found on it is  particularly good example of this practice at work.

There are however cases where being strict with your inputs is appropriate. These tend to be when the input is a request to perform an action. In such cases allowing ambiguous input to be processed can cause confusion at best and corrupted data at worst. In a request to perform an action is ambiguous then in most cases the best option is to throw an appropriate error describing the problem rather than attempt to guess. Guessing the users intention is hazardous as the average user may want almost anything. This is even true when you are that user.

As an example on a project I’m associated with we recently had an issue with a simple update request failing. This request was a batch that requested updated to multiple items in a single request. When the client made the request the service was rejecting it in a consistently replicateable fashion. Due to this rejection an important business function was blocked.

The relevant code in the service was written by me and it was acting as I intended. The input from the client was ambiguous. Included in the batch were items that were not being updated but were still being included in the request. The service considered this to be erroneous and failed the request. It did so because it had no defined behaviour for the items, yet they were still being submitted with comments and other associated data. If the service decided to just ignore this data then there was the possibility that user input from the client could simply be discarded. The client would assume that as it had passed the data to the service it had been recorded where this was not the case. Such an assumption could be seriously negative if the business ever needed to rely on this data again for commercial or legal reasons.

Even though this behaviour surfaced with an end user (which is never ideal) I still consider this to be a good example of where being strict with inputs has been beneficial. This issue occurring gave an indication that the client was potentially not interacting with the service correctly and was making unwarranted assumptions about its behaviour. This potentially applies to interactions beyond this single update request. What we have gained therefore is an understanding that an entire class of bugs is possible and have guaranteed that we will not ignore or misprocess data we don’t know how to handle. We have also gained additional knowledge to apply to our testing process in future.

It should be noted that in some scenarios this behaviour may not be applicable. If there is a long lead time between making a fix and being able to apply it selectively to production then the risk of errors that cause data loss and incorrect behaviour must be weighted against errors that prevent a business process being completed. In the environment above we are able to quickly release fixes (due to such factors as the presence of a Continuous Integration server that runs our unit test suite). Where your process moves slowly you may need to consider alternate compensation mechanisms.