In a recent chat iwth Daniel Bodart, I realised that after programming Java over the past few years, it offers programming an open option of handling bugs. Handling errors needs great care and scrutiny and care. When writing error handling code one has to decide – do you really want to handle the code?
It’s not too uncommon to encounter a code which logs every single error (e.g. user did not enter his telephone number in the online form) into a log file. This results in a horribly long, few gigs of error log file daily depending on site usage. Then looking through that file is like finding needle in a haystack, unless the large log file in itself does not cause issues serious enough (system hangs, time consuming to search).
The idea here is to either handle an error as it is if possible to handle it, otherwise should we let the system crash on errors we don’t know how to handle giving the user a negative experience.
If we had 10,000,000 users signing up for a £20 service. The system does not work for 0.05% of them which results in 5,000 users having issues resulting in £100,000 direct loss of potential revenue. It also depends on how fast the technicians are in catching the error, thus if we catching it after 1,000,000 users used the system, the direct loss of potential revenue will be reduced by a 10th to £10,000, all the while causing no issues that the remaining users that might have had the same problem. But any potential loss is hit on the revenue and needs to be balanced out.
