Quote:
|
Originally Posted by Jessehk
The book I am reading just spent a about 10 pages with exceptions (relative to the other material, not much), and I just wanted to clarify things. I now know about the standard exception class, and how to use them. I wanted to get clarification on their proper use. Now, I know they are mostly used for input errors, memory allocation errors, bounds errors, etc.
|
More generally, exceptions are used to report errors that, if ignored, can cause irrecoverable errors in the program. By throwing an exception in such cases, it is guaranteed that the error will either be handled (and presumably recovered from) or the program will exit.
Memory allocation errors are a good example: in most cases, it is not possible for a program to recover if an error occurs when allocating memory. However, if it is possible in a particular program to recover from a memory allocation problem, then all that program needs to do is catch the relevant exception. This is one reason that operator new, by default, throws exceptions if an error occurs.
Input errors is one example where it it not necessarily a good idea to throw an exception. For example, one of my pet peeves in Java is that an exception is thrown on end of file by some operations: this complicates things enormously when a program is doing something along the lines of (in pseudo code)
if (read_data_from_file() != EOF)
process_data(); which becomes;
try
{
read_data_from_file();
process_data();
}
catch (eof_occurred)
{
} which is a more complicated way of doing the same thing.
Quote:
|
Originally Posted by Jessehk
However, what their use to solve a simple problem also be considered "acceptable"?
|
Generally, it is best to use the way of reporting errors that is best suited to the scenario at hand. If an error can be recovered from at the point where it is detected, throwing an exception is not a good idea. If an error can NOT be recovered from at the point where it is detected, throwing an exception is a good idea if chaos would occur if recovery actions did not happen. If an error can NOT be recovered from at the point where it is detected, throwing an exception is NOT a good idea if the program can continue to execute happily even if recovery actions do not occur.
A clue that throwing exceptions are a bad idea is if you find yourself continually writing throw/catch blocks concerned with little more than ignoring the error. Another clue that throwing exceptions is a bad idea is if MANY function has to include try/catch blocks: as a rough rule, most functions should happily let an exception pass through if nothing can be done about it.
A clue that throwing exceptions is a good idea is if you find yourself having to track down instances where you have forgotten to check a return status from a function that reported an error.
I would suggest that catching an exception within the function that threw it is NOT a good idea, although it is not necessarily "wrong". Would it be a better idea to check the return value from password.check() and print an error message if a failure has occurred? As a rough rule, the code that is easiest to read is often best. And I would suggest an approach without exceptions would be simpler.