# Should answers have to handle invalid inputs?

I'm trying to get advice on how to make my challenges better. One rule that I feel like I'm always specifying is what to do when an invalid input is given. There's really two main paradigms to take here. Either

• No invalid inputs will be given. Invalid input results in undefined behavior. or

• Inputs might be valid, and might be invalid. If they are invalid, you must clearly output that the input was invalid, e.g. by printing an error message, or a falsy value, or some other method.

Now obviously, this won't result in any hard-fast rules about challenge-writing, but I'd like to get your opinions. Is a challenge more interesting/better written if it uses the first method or the second?

• Too few alternatives. There are at least 4, not 2. – Qwertiy Apr 1 '16 at 18:07
• @Qwertiy There's an answer button down there for you to enlighten us all with the enumeration of the latter unprecedented options :P – cat Apr 1 '16 at 19:38
• @cat, but I used it ;) – Qwertiy Apr 1 '16 at 19:50
• @Qwertiy I'm on the mobile site, it's not like I can read anything anyways ;) – cat Apr 1 '16 at 19:57
• @Qwertiy there's another possibility that you missed. It's quite common for answers to be required to handle mildly invalid input (such as a set of numbers on which a particular calculation cannot be performed) but not grossly invalid input (for the above example, input that isn't even numbers.) This type of situation should be (and usually is) specified in the question. – Level River St Apr 12 '16 at 14:54
• Note that in some languages, validating inputs is in general impossible. For example, in Underload, it's possible to produce a value that can't be inspected in any way without producing predetermined output and then crashing the program; if the program needs to react in any way to the input, it runs the risk of triggering such a badly-behaved input. So you'd need to give a description of what sort of possibly-invalid inputs can occur for this to be fair among languages. – user62131 Apr 24 '17 at 23:39

# No, invalid inputs may result in undefined behavior

Requiring input validation only adds extraneous code to the answer and takes away from the challenge.

• For most cases, I'd agree with this answer. But what about challenges where it's possible to validate input without a great deal of extraneous code, (e.g. as a consequence of some nice formula the code uses)? – Sp3000 Apr 1 '16 at 12:36
• @Sp3000 I would say you could write a challenge where the main point is parsing the input. Then it's perfectly fine to require at least some level of input validation. – John Dvorak Apr 2 '16 at 10:08
• I think this is the best default behavior (which is why I accepted it) but I think it's worth pointing out that some amount of input validation could be OK. For example, a primality testing answer could need to check for numbers < 2, but shouldn't be required to handle strings. Obviously, this depends on the challenge and needs to be specified by the OP. – James Apr 12 '16 at 14:59
• @Sp3000 it’s possible to just post both variants (in the same post, not separately!). The Challenge is fulfilled with the nonvalidating one, the other is for extra points in the B note, or extra karma ;) – mirabilos Apr 12 '16 at 21:56
• What I have to say... The above it is wrong and blu error – user58988 Dec 1 '17 at 12:26

# By default valid input is guaranteed

If it's not, some behaviour should be specified:

• Any behaviour (but why specify this when it's defeult?)
• Handle it in some way and produce a specific value
• Produce any value in finite time without exceptions
• Produce any value or exception in finite time

I believe that the default for challenges is "you will only be passed valid input and do not have to handle invalid input in a certain way". I make this clear in my challenges at least.

• I think it would be nice to have such a default but I don't know that we have one currently. Do you have a source for that? – Alex A. Apr 1 '16 at 0:55
• @AlexA. I remember asking this same question in chat before and this is the answer I got. Ill try to find the message but I may be remembering wrong. – GamrCorps Apr 1 '16 at 0:56
• @AlexA. I assumed it was implicit when challenges describe the possible inputs, but I guess we should state it. – xnor Apr 1 '16 at 0:59
• @xnor Yeah. I think it's always better to have an explicit policy we can point to. – Alex A. Apr 1 '16 at 1:00

# In few words

The function + the compiler/interpreter has to handle/ return the correct result or, in case of error show error (or when error is find or when the result of computation is show) in all possible input the function can receive.

• I disagree. If not specified otherwise by the author of a challenge, you should assume that inputs are always valid. If you've got to implement error handling in every challenge, it takes away a lot of fun and a lot of golfing potential. And usually the user of a function has to make sure to use a function correctly. – Luca H Dec 1 '17 at 13:00
• Programming is this and that too – user58988 Dec 1 '17 at 13:19
• I don't have a clue what you are trying to say. – Luca H Dec 1 '17 at 14:21
• Please clean up your english, it's very hard to understand what you mean. – Rɪᴋᴇʀ Dec 1 '17 at 18:32