I did a little mapping out of different error types a developer might encounter. It should be useful for junior developers but even more experienced developers might find the classification worth discussion.
The most basic errors are syntax errors, such as typos. These are also called compilation errors as they can usually be detected when compiling the code. In intercepted languages (such as javascript) merely loading the file (in the browser) will produce an error. So they're easy to spot and easy to fix as the compiler/browser can easily point out the part that didn't make sense to it. Having a good IDE (Integrated Development Environment), should save one the need to actively compile as the IDE itself will warn when it'll notice that things don't make sense.
Things can get trickier when the typo is "i" instead of "j" (for index variables), for example. True this is a mere typo but if such a variable exists, the compiler won't complain and we'll get a semantic error or a Logical error. In this case, the programme will run but will not do what was expected of it. And now the things might happen - the good case is that the programme will crash or have any other clear indication that something is wrong; the bad case that the programme will run normally but occasionally (depending how deep is the typo buried) produce wrong results.Having (automated) tests that check your code works as expected should help you avoid semantic error.
Another kind of error are runtime errors. These happen when the running code does something the developer didn't expect, such as trying to access an out-of-bound array item, or when the user enters invalid input. Brenan Keller told the following story -"A QA engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 99999999999 beers. Orders a lizard. Orders -1 beers. Orders a ueicbksjdhd;First real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone.".It's true that not everything can be predicted, and therefore it's always good to have try{}-catch{} segments around shady parts of your code - namely user input and data fetched from external sources.
But all these were the easy errors. The difficult errors are the ones you don't see coming - Randomosity errors, such as race-condition errors.Consider the following story - A software company was struggling to find the cause for their systems to crash every night, but when left unattended as whenever an engineer left to monitor the activities overnight, everything seems to be working fine. It took them a while to realise it was the screensaver causing the crash so whenever the engineer checked the system he simply prevented it from going to screen-saver mode.There is no clear solution how to avoid such errors but there are measurements one can take to eliminate alternative causes - such as testing units separately, integration between the units and testing end-to-end to try guesstimating what might differ in the failing scenario.
Similarly, There are issues that don't make sense. Consider the following story (well elaborated by Abdul Nasir Shaikh) about a customer complaining to General Motors that his car won't start whenever he buys vanilla ice-cream, while all other flavours seems to work alright. As ridiculous as it may sound, GM sent an engineer to investigate and he learnt that since vanilla ice-cream, being a popular flavour, is located at the front of the store, the engine doesn't have enough time to cool down, while the rest of the flavours were at the back and posed no issue. The overheating problem was fixed and everybody was happy. It's important to note that the error was as real as it gets, but its phrasing sounded odd. When trying to solve such a mystery, it's always important to question if we frame the problem correctly.
And lastly, we have the all-time favourite "It's a feature, not a bug". Consider the following video -
Another example would be the iPhone's limited multi-tasking capabilities. Although some multitasking is possible, most of the iPhone apps hibernate whenever they're not in use. In most scenarios it makes sense, however it has been a long-time rant that it's not possible to play youtube videos in the background. The "feature" can be justified, at least from the developer's point of view, but for the user who complains about the bug - it's a failure of understanding the user's need.
And that is the worst kind of error a programme might have- it's working just fine - but it doesn't behave how the user expected it to. Behaviour-driven-design should resolve such issues, but that is assuming of course there weren't any errors in the behaviour-analysis stage itself, which is usually outside the developer's scope.
To surmise - compilation errors shouldn't be an issue at all; logical errors should be covered by proper tests, random errors can be avoided by keeping high test coverage and behaviour-driven design should help avoid "feature-not-a-bug" error when done right. I think it's useful to frame the error in the right context.
Surely you have fancy investigative/facepalm bug stories of your own. I would appreciate if you can share them in the comments - especially if they don't fall under any of my categories ;-)
Top comments (0)