current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 1 down vote favorite

This is a very naive question about input validation in general.

I'm a MATLAB user (1.5 years old) and I learned about input validation techniques such as "parse" and "validatestring". In fact, MATLAB built-in functions are full of those validations and parsers. So, I naturally thought this is the professional way of code development. With these techniques, you can be sure of data format of input variables. Otherwise your codes will reject the inputs and return an error.

However, some people argue that if there is a problem in input variable, codes will cause errors and stop. You'll notice the problem anyway, and then what's the point of those complicated validations?

Given that codes for validation itself take some efforts and time, often with quite complicated flow controls, I had to admit this opinion has got a point. With massive input validations, readability of codes may be compromised.

share|improve this question

2 Answers 2

up vote 3 down vote accepted

The basic issue is how easy it is to understand and correct the input error.

If you have a short, simple sequence of "input x"... "number too large error, crashing" then the input validation is not really important. But when the user spends more than a few seconds entering information you either preserve it so they can resume where they left off, of they will get annoyed. Likewise, if they realise an earlier value was wrong they want to go back and edit it. Preserving input and jumping around in it means you now have to verify the saved values (did the user edit the saved values file?).

Or you skip the prompt-and-type cycle and go straight to a file. Matlab likes big files of input numbers. But very quickly you find yourself with a big "input" file that has to be verified. Having error messages that say "on line 8637 the 18th value is a float where it should be an integer between 0 and 400" is very handy. Albeit you shouldn't have 18 values on one line if you can avoid it. They're annoying to generate, but for the user "your 30,000 line file has an error, see if you can find it" is utterly unhelpful.

I once spent a month writing an "input file generator" for a scientist to use. He was feeding files into a big Fortran application that ran on a supercomputer, and it was very prone to the above type or message. It would run for an hour or two, then say "invalid profile". Not even "profile number 37 is invalid", just "something bad happened". So I wrote a GUI application that would load the file, parse it out and display it in an editable way, then save it as a valid input file for the big machine. Ugly as anything, lots of nested page controls and big grids, but usable. It was cheaper to pay me to do that than keep paying for supercomputer time that led to stupid error messages. And it dramatically sped up their work - instead of starting with a file they knew worked and modifying it one step at a time, feeding each one into their local slow computer and seeing if it ran overnight would an error, they could do a heap of edits in my program then verify it locally with great confidence that it would work.

share|improve this answer
    
> for the user "your 30,000 line file has an error, see if you can find it" is utterly unhelpful. I agree! I often use "parse" method of inputParser class in MATLAB, to validate input arguments. With that, I can concentrate a lot of lines of validations into a validation function as an anonymous function and validate many inputs at once in one line. The code can be concise. However, when inputParser gives an error, it doesn't tell me which portion of the validation function the input variable failed to pass. I can only tell that input variable 1 failed to pass validation function 1. –  John Smith Jan 25 at 14:44
    
This isn't good, is it? To get more detailed error message, however, I may have to dissect the validation function 1 into many "if" blocks, and write different error messages for each. This would take so many lines and time. Thus, here is another trade-off. Which is better, compressed validations or lengthy spaghetti validations? –  John Smith Jan 25 at 14:50
    
@John Smith: I try to do more than one level. I start with "parse the input", then "validate input" which goes through every value and checks that it's sensible. This is where the exact error location is discovered, so I generally run it even if parsing failed. I'm not a Matlab programmer so I can't advise on the specifics, sorry. In a traditional language another way is to use state descriptors, so at each step you set a "current error message" (along with "current line" "current position"), then call a generic "parse next value" function that reports those if there's an error. –  Ӎσᶎ Jan 25 at 20:36
    
Basically more lines for validations and error reports, then, if I want to know the exact problem at once. There may be an inevitable trade off. Perhaps that trade off naturally determines how far I should go for each case. It's good to hear about this kind of general idea. Thanks a lot! –  John Smith Jan 27 at 1:14
    
FWIW, I just wrote a simple C++ method that uses three values... it's three lines of functionality with 24 lines of error detection and logging. That's unusual, but not exceptional. Each value can be missing or invalid, so there's a lot of error paths and the success path is very simple... but you call "DecodeReplyMessage(string) returns ErrorCode" and never have to look at the interior. (C++ exceptions are often a nightmare, so I use return codes) –  Ӎσᶎ Jan 28 at 22:25
up vote 4 down vote

if there is a problem in input variable, codes will cause errors and stop.

A problem in inputs or code will cause errors and stop only if you're lucky. If you're unlucky, a problem in an input variable will cause an incorrect but plausible result.

Incorrect but plausible results are bad, because you think you've got the correct answer, and you think the problem is solved, so you move on to the next step of whatever it is you're doing, using an incorrect value. And the consequences of using an incorrect value that you think is correct can be huge - see did an Excel coding error destroy the economies of the Western world?.

share|improve this answer
    
Aha, it's just a luck? I see what you mean. I like the simplicity of your answer. A code with slightly wrong input may survive, and it would be very hard to notice! –  John Smith Jan 25 at 14:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.