A prior question had an answer that interested me from a design perspective. I work in geospatial data and occasionally have to deal with voids when I read these binary files into my product. What is the best way to deal with voids when reading them in - throw an exception when you encounter them or return immediately. I believe one of the answers that I read talked of returning rather than throwing an exception. Currently I return rather than throw an exception. But I was wondering whether that is the best approach.
When deciding between throwing an exception or returning an error-code, there are a few considerations to take into account.
The primary one is how exceptional is the situation. Is receiving data with voids in them something that should not happen (and an indication that somewhere else something went really wrong), or is that something that your algorithm is supposed to be able to deal with gracefully. If it should not happen, then that is a strong indicator for using an exception.
A second consideration that I often use (and opinions are divided if it is a valid consideration) is if the immediate caller can be expected to resolve the problem. If I know beforehand that the immediate caller is unlikely to be able to do anything about an error I signal, except to pass the buck up the call chain, then I am more inclined to use an exception to report the error because it is less error-prone to let an exception go up the call chain than to report an error-code up several levels.