R. Clayton (rclayton@monmouth.edu)
(no date)
The procedure in my code that checks the input for errors returns a vector, so
I'm not sure how to return an error indication if the procedure finds something
wrong.
You can put a reference parameter in your procedure and use that to pass back
an error indicator:
std::vector<ins> check(std::vector<std::string> inp, int & error) { ... }
I find this style of programming ugly (because it's difficult to recognize
reference parameters by looking at the call), but that's a personal
prejudice.
The procedure could use an assertion to signal the error, or it could throw an
exception.
The principle reason you shouldn't use assertions to check for input errors
is that assertions can be turned off, which would disable your program's
input checking.
You could use exceptions, but now we can have a debate about whether input
errors are exceptional or not. I don't think they are, and that they should
be handled via normal control- and data-flow mechanisms; other people (java
programmers, in particular) might have equally good reasons that input errors
are exceptional.
Failed assertions abort the program after printing a message, which is not
good, right?
Right. Failed assertions leave a mess behind, and they provide no
opportunity for recovering from the error.
Exceptions can more cleanly handle this problem, but you said exceptions are
nasty and shouldn't be used.
That's my opinion; you should form your own opinion. Try them out and see
how you like them.
Another possibility is to just print a message and exit the code.
True, but the question is: where should the error message and exit take
place? The easiest thing to do is print the message and quit at the place
where the error is discovered. However this is usually considered bad
programming practice because it denies the higher-level software a chance to
recover from the error, or otherwise deal with it.
The alternative is to pass an error indication up to the higher levels and
let them deal with it. From a software engineering standpoint this is the
better of the two solutions, but it's also harder to design and implement,
particularly if some of the value-passing features of the language are
unavailable (as they are in constructors and overloaded binary operators).
Any suggestions?
One solution that I'm fond of is to create a special error value that acts
otherwise like an input value. For example, in the first programming
assignment, I had three types of strokes: nodes, edges and errors. If any
part of the program found an error, it would just add an error stroke to the
list and pass the list on. As other parts of the program find the error
stroke, they would do the same. Finally, the output routine looks for the
error value and prints that; otherwise it prints the legal output.
This technique has some problems (repeatedly checking for the error value
tends to complicate the program logic), but on the whole I find it a
relatively simple, non-disruptive method for handling errors.
This archive was generated by hypermail 2.0b3 on Fri May 09 2003 - 15:30:05 EDT