Question

Suppose I’m writing a library that stores a sequence of doubles to a file in a certain format. The format requires that the doubles are monotonically increasing.

Now, some users won’t read the manual carefully or write buggy frontends that do something like

store(3.0)
store(3.1)
store(0.3)
store(7.8)

What the library could do is

1. Error out when store(0.3) is called.
2. Try to correct the error by making a good guess, e.g., actually store(3.3).
3. Correct the error and write a message to stderr.
4. […]

The advantage of (1) would be that the user cannot miss it. If the code ran for a long time (which is the regular case in my context), though, the user wouldn’t be too happy with the program aborting.
(2) would do away with this, but possibly encourage misusing the library.

Are there policies in any language that advocate one approach over the other?

Answer 1

Irrespective of the language used, my general advice is to always fail quickly. This localises errors to the actual source of the problem – i.e., throw an error or exception and bail out (perhaps permitting the programmer to catch the exception, depending on the language). Similarly, some languages with checked exceptions might force the programmer to add a check for malformed input.

The reason for this is simple – the further away from the actual source of the problem that the errors manifest, the harder the program is to debug. Let’s say the programmer didn’t mean 3.3 (as opposed to 0.3) and you corrected it for him – well, the program will keep running, but at some point the value 3.3 will manifest and potentially cause other problems. It might also be that the source of these values was some kind of sorting algorithm with bugs – the fact that your library doesn’t fail in this case will simply make it harder to debug the sorting algorithm and identify the real cause of the failure.

It also plays hell with any attempts to unit test the code – code that should fail doesn’t necessarily fail in the right place. This just makes the code magical and much more difficult to manage as part of a development process.

There is an alternative to simply failing and forcing the user or client program to start the interaction all over again – you could do things in a transactional manner such that the library is left in a consistent state after the failure, permitting the user to proceed from the last valid input (for example). This should be implemented with proper rollback semantics though, to ensure data consistency.

So in summary: fail fast, and fail early.