Question

So, I was just coding a bit today, and I realized that I don’t have much consistency when it comes to a coding style when programming functions. One of my main concerns is whether or not its proper to code it so that you check that the input of the user is valid OUTSIDE of the function, or just throw the values passed by the user into the function and check if the values are valid in there. Let me sketch an example:

I have a function that lists hosts based on an environment, and I want to be able to split the environment into chunks of hosts. So an example of the usage is this:

listhosts -e testenv -s 2 1

This will get all the hosts from the “testenv”, split it up into two parts, and it is displaying part one.

In my code, I have a function that you pass it in a list, and it returns a list of lists based on you parameters for splitting. BUT, before I pass it a list, I first verify the parameters in my MAIN during the getops process, so in the main I check to make sure there are no negatives passed by the user, I make sure the user didnt request to split into say, 4 parts, but asking to display part 5 (which would not be valid), etc.

tl;dr: Would you check the validity of a users input the flow of you’re MAIN class, or would you do a check in your function itself, and either return a valid response in the case of valid input, or return NULL in the case of invalid input?

Obviously both methods work, I’m just interested to hear from experts as to which approach is better 🙂 Thanks for any comments and suggestions you guys have! FYI, my example is coded in Python, but I’m still more interested in a general programming answer as opposed to a language-specific one!

Answer 1

Good question! My main advice is that you approach the problem systematically. If you are designing a function f, here is how I think about its specification:

1. What are the absolute requirements that a caller of f must meet? Those requirements are f‘s precondition.

2. What does f do for its caller? When f returns, what is the return value and what is the state of the machine? Under what circumstances does f throw an exception, and what exception is thrown? The answers to all these questions constitute f‘s postcondition.

   The precondition and postcondition together constitute f‘s contract with callers.
   Only a caller meeting the precondition gets to rely on the postcondition.

3. Finally, bearing directly on your question, what happens if f‘s caller doesn’t meet the precondition? You have two choices:

   • You guarantee to halt the program, one hopes with an informative message. This is a checked run-time error.

   • Anything goes. Maybe there’s a segfault, maybe memory is corrupted, maybe f silently returns a wrong answer. This is an unchecked run-time error.

   Notice some items not on this list: raising an exception or returning an error code. If these behaviors are to be relied upon, they become part of f‘s contract.

Now I can rephrase your question:

What should a function do when its caller violates its contract?

In most kinds of applications, the function should halt the program with a checked run-time error. If the program is part of an application that needs to be reliable, either the application should provide an external mechanism for restarting an application that halts with a checked run-time error (common in Erlang code), or if restarting is difficult, all functions’ contracts should be made very permissive so that “bad input” still meets the contract but promises always to raise an exception.

In every program, unchecked run-time errors should be rare. An unchecked run-time error is typically justified only on performance grounds, and even then only when code is performance-critical. Another source of unchecked run-time errors is programming in unsafe languages; for example, in C, there’s no way to check whether memory pointed to has actually been initialized.

Another aspect of your question is

What kinds of contracts make the best designs?

The answer to this question varies more depending on the problem domain.
Because none of the work I do has to be high-availability or safety-critical, I use restrictive contracts and lots of checked run-time errors (typically assertion failures). When you are designing the interfaces and contracts of a big system, it is much easier if you keep the contracts simple, you keep the preconditions restrictive (tight), and you rely on checked run-time errors when arguments are “bad”.

I have a function that you pass it in a list, and it returns a list of lists based on you parameters for splitting. BUT, before I pass it a list, I first verify the parameters in my MAIN during the getops process, so in the main I check to make sure there are no negatives passed by the user, I make sure the user didnt request to split into say, 4 parts, but asking to display part 5.

I think this is exactly the right way to solve this particular problem:

1. Your contract with the user is that the user can say anything, and if the user utters a nonsensical request, your program won’t fall over— it will issue a sensible error message and then continue.

2. Your internal contract with your request-processing function is that you will pass it only sensible requests.

3. You therefore have a third function, outside the second, whose job it is to distinguish sense from nonsense and act accordingly—your request-processing function gets “sense”, the user is told about “nonsense”, and all contracts are met.

One of my main concerns is whether or not its proper to code it so that you check that the input of the user is valid OUTSIDE of the function.

Yes. Almost always this is the best design. In fact, there’s probably a design pattern somewhere with a fancy name. But if not, experienced programmers have seen this over and over again. One of two things happens:

• parse / validate / reject with error message

• parse / validate / process

This kind of design has one data type (request) and four functions. Since I’m writing tons of Haskell code this week, I’ll give an example in Haskell:

data Request -- type of a request
parse    :: UserInput -> Request            -- has a somewhat permissive precondition
validate :: Request -> Maybe ErrorMessage   -- has a very permissive precondition
process  :: Request -> Result               -- has a very restrictive precondition

Of course there are many other ways to do it. Failures could be detected at the parsing stage as well as the validation stage. “Valid request” could actually be represented by a different type than “unvalidated request”. And so on.