Unhandled Exception sounds like one of those euphemisms people create these days to take away the feelings of saying “error” or “crash”. However Unhandled Exception is a term that a developer should understand and use more specifically to identify what it describes actually: An … Unhandled Exception.
Imagine a program that would be used to tell a person how many fingers to show in each hand given an input. So if we input A, it tells you should show the left thumb, if B, it tells you should show the left indicator, so on and so forth. When you reach the J, you start getting 2 fingers interpreted, so K would be two thumbs. As there are less letters than the code for fingers to show, it goes smootlhy all the time, because no matter what letter you bring, there are always fingers to show for it. No problem, NO EXCEPTION to Handle.
Then, here comes a imaginative DEV creating a “Sorcery Update” (update of any kind, it is just a funny whim). Then the feature is decided to be both ways, so if you input a letter, it tells which fingers to show, and if you input finger setup, it shows a letter.
Another Dev, or the same one (might happen), decides to use it to create words, because “why not”. And then there is a wonderful new feature with that update.
Initially there were NO EXCEPTIONs, but now there are EXCEPTIONS in which the rule cannot apply. Software does not create errors from “thin air”. If there are no use for a component you mention but no memory is allocated to it, there are not memory allocation errors because it is never used. However, when you try to use it without proper verification, allocation might not be what you expect, so you create an EXCEPTION, and that is never a problem if it is handled by clamping the value of input, mapping range, or simply checking if it is a valid one.
We know as developers that no one can develop extensive software never leaving a single exception unhandled. However, when someone points out that there was an unhandled exception, it is not actually a smart solution to simply acquire that specific exception but leave the rule alone.
So, it is nice to get some IsValid, or Contains, or Length, even if we might “KNOW” that it will always be valid, always contain, or always be inside the length, but just to be sure. It becomes second nature after a while, and less Unhandled Exceptions come about when you get that practice.
And a warning in development is never just a warning. This is not traffic police.
