To my way of thinking, the presence of a blank line could be a significant and intentional part of the input. It could also be “an intended stricture of the data,” i.e. “deviation from which indicates bad data,” if more-than-two or other-than-two nonblank strings occur betwixt the blanks (or if only one nonblank instead of two appear at the end). I generally believe that it ought to be the program’s responsibility not only to do the right thing in all cases, but to detect and report anything that is designated to be not-the-right situation with regard to its own inputs. (Otherwise, you might well have a malfunction ... or, worse yet, unrecognized incorrect-output ... because no one is in the position to detect the flaw or to call attention to it other than this program itself.)

The FSM-approach that I outlined previously will, in a very implementable and adjustable way, enable this sort of thing to be done. Obviously, every case is different, but I do find that this has consistently benefited my projects.

I guess what I’m driving at is ... there is one sort of approach which says, “okay, it seems to work so I’m done.” But there is also another approach which allows one to say, “because this program completed without error, we can assert, not only that the output is good, but that the inputs also were good.” All 1,771,561 of them. Extremely do-able, and of course, frequently beneficial.