17
\$\begingroup\$

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?

\$\endgroup\$
6
  • 1
    \$\begingroup\$ Too few alternatives. There are at least 4, not 2. \$\endgroup\$
    – Qwertiy
    Commented Apr 1, 2016 at 18:07
  • 2
    \$\begingroup\$ @Qwertiy There's an answer button down there for you to enlighten us all with the enumeration of the latter unprecedented options :P \$\endgroup\$
    – cat
    Commented Apr 1, 2016 at 19:38
  • \$\begingroup\$ @cat, but I used it ;) \$\endgroup\$
    – Qwertiy
    Commented Apr 1, 2016 at 19:50
  • \$\begingroup\$ @Qwertiy I'm on the mobile site, it's not like I can read anything anyways ;) \$\endgroup\$
    – cat
    Commented Apr 1, 2016 at 19:57
  • 1
    \$\begingroup\$ @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. \$\endgroup\$
    – Level River St
    Commented Apr 12, 2016 at 14:54
  • \$\begingroup\$ 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. \$\endgroup\$
    – user62131
    Commented Apr 24, 2017 at 23:39

4 Answers 4

Reset to default
51
\$\begingroup\$

No, invalid inputs may result in undefined behavior

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

\$\endgroup\$
5
  • 3
    \$\begingroup\$ 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)? \$\endgroup\$
    – Sp3000
    Commented Apr 1, 2016 at 12:36
  • \$\begingroup\$ @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. \$\endgroup\$
    – John Dvorak
    Commented Apr 2, 2016 at 10:08
  • 1
    \$\begingroup\$ 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. \$\endgroup\$
    – DJMcMayhem
    Commented Apr 12, 2016 at 14:59
  • \$\begingroup\$ @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 ;) \$\endgroup\$
    – mirabilos
    Commented Apr 12, 2016 at 21:56
  • \$\begingroup\$ What I have to say... The above it is wrong and blu error \$\endgroup\$
    – user58988
    Commented Dec 1, 2017 at 12:26
15
\$\begingroup\$

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
\$\endgroup\$
7
\$\begingroup\$

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.

\$\endgroup\$
4
  • \$\begingroup\$ 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? \$\endgroup\$
    – Alex A. Mod
    Commented Apr 1, 2016 at 0:55
  • \$\begingroup\$ @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. \$\endgroup\$
    – GamrCorps
    Commented Apr 1, 2016 at 0:56
  • 2
    \$\begingroup\$ @AlexA. I assumed it was implicit when challenges describe the possible inputs, but I guess we should state it. \$\endgroup\$
    – xnor
    Commented Apr 1, 2016 at 0:59
  • 1
    \$\begingroup\$ @xnor Yeah. I think it's always better to have an explicit policy we can point to. \$\endgroup\$
    – Alex A. Mod
    Commented Apr 1, 2016 at 1:00
-10
\$\begingroup\$

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.

\$\endgroup\$
4
  • 3
    \$\begingroup\$ 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. \$\endgroup\$
    – Luca H
    Commented Dec 1, 2017 at 13:00
  • \$\begingroup\$ Programming is this and that too \$\endgroup\$
    – user58988
    Commented Dec 1, 2017 at 13:19
  • 4
    \$\begingroup\$ I don't have a clue what you are trying to say. \$\endgroup\$
    – Luca H
    Commented Dec 1, 2017 at 14:21
  • 4
    \$\begingroup\$ Please clean up your english, it's very hard to understand what you mean. \$\endgroup\$
    – Riker
    Commented Dec 1, 2017 at 18:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .