This problem concerns the robustness of the number-sorting program written for Column 1, Exercise 3. Unfortunately, it is extremely difficult to answer questions about how you would handle error conditions without a pretty specific definition of the user requirements. The column gives only a cursory description of the problem that is being addressed, and so it is difficult to deduce these requirements.
In any case, here are my responses to the posed questions.
The program as sketched has several flaws. The first is that it assumes that no integer appears twice in the input. What happens if one appears more than once?
First of all, I don’t think that this is a flaw: After all, it was a stated assumption that each number only would appear once.
There are two major components to the sorter: The bit vector that tracks what numbers have been ‘seen’, and the sorting program that actually does the dirty work of reading in the data and using the bit vector to implement the sort.
My opinion is that the bit vector should have very strong pre- and post-conditions on its methods (a design-by-contract approach). The Set(i) method should have as one of its preconditions !Get(i). Thus, the program will crash hard if the same bit is set twice.
This means that it is up to the sorting program to detect this error condition, very simply by checking Get(n) for each integer n read from the input.
How could the program be modified to call an error function in this
case?
I don’t like this question because it is very language-specific. Some languages could raise an exception, others could provide a callback, etc. and given that we don’t have any solid requirements, hashing out a specific error-handling scheme seems like a fruitless exercise.
What happens when an input integer is less than zero or greater than
n?
Again, strong preconditions in the bit vector would cause an assertion failure if this condition is not handled in the sorting program that is using it as a client. So, the question is, what should the sorting program do to handle this condition?
This of course depends on the user requirements. If you wanted to make sure that _all_ numbers were accounted for in the final input, even if they were wacky, you could do an initial pass of the data, and find the largest and smallest numbers. You could then create a bit vector of size largest - smallest and do the necessary offsetting when accessing the vector and printing the results. If there is a legal range for the input based on user requirements, then these `outlier’ data could be discarded, or could result in an error being transmitted to the user depending on a policy formulated from the requirements.
What if an input is not numeric? What should the program do under these circumstances?
If the entire input is not numeric, than this approach is probably not a good one (although one could hash each datum and map it to its actual value, and create a bit vector that tracks these hashed keys.)
If only some part of the input is not numeric, one has to decide (once again, based on requirements) if this data has the potential to be `good’, or if it is just garbage. Garbage inputs could be discarded, or could cause an exception to be thrown or a callback to be fired, etc.
If the programming language used allows dynamic typing, it may be necessary to put preconditions on the bit vector methods to ensure that the index being passed into the Get and Set methods is actually an integer.
What other sanity checks could the program incorporate? Describe small data sets that test the program.
To repeat myself one last time, it’s really hard to reasonably specify this sort of thing without some minimal requirements or specifications, since it’s generally around this time that you think about your exceptional-case handling strategy. Also, this discussion relies on the facilities your language provides you, and what sorts of errors it catches at compile-time so that you don’t have to do the explicit checking.
Of course, one could simply overengineer the hell out of the thing in the absence of sufficient requirements gathering, but that seems like a waste of effort 
Comments (0)