There are errors and there are exceptions. Admittedly, “errors” and “exceptions”, are not universally agreed upon names for the things we will describe, but what’s more important here is the difference between them.
There are errors.
An error means something the user wanted to do didn’t work out. This might have been unexpected for the user, but not for the developer.
An error is shown in a nicely formatted dialog window, letting the user know what didn’t work out, why it didn’t work out and what they can do now.
Then there are exceptions.
An exception means something went wrong with the program. It’s not about the user violating the business rules, but about the programmer violating the language’s rules.
For example, the most prominent one, a
NullReferenceException, means the programmer tried to access a member from a null reference and that is not allowed in C#.
Exceptions out of your control
If it’s out of your control if exceptions are thrown or not, they should be caught immediately and then evaluated in the context of your program.
If a library throws an exception when some user input you provide to it is not in the correct format, it should be caught and turned into one of those errors we previously described
Another example would be a
FileNotFoundException. The hard drive could be yanked out of the computer at the exact moment your code tries to work on it and there’s just no way you can do anything about that with code. So if a user tries to save a file, catch any
FileNotFoundException that might occur and turn it into another nicely formatted error for the user.
Next Article: Encapsulate Collections