2
\$\begingroup\$

Should programs be able to output to STDOUT, when the question says you must "error"?

For example, the python program 1/0 outputs ZeroDivisionError: integer division or modulo by zero. This is to STDERR by default.

But the program:

print "ZeroDivisionError: integer division or modulo by zero"

Echos the same thing, but to STDOUT. There is no observable difference in the output of the first and the last program, save the STDOUT/STDERR issue.

In addition, we already allow output to be piped to STDERR as a standard i/o method.

Some programming languages, such as Mathematica, even output errors to STDOUT by default.

So, should we allow answers to output to STDOUT when an "error" is requested?

And the opposite should also be considered: what about answers that output errors to STDOUT, which would normally fall under the "No Extraneous Output" rule?


Related: Programs may output to STDERR

\$\endgroup\$
  • 2
    \$\begingroup\$ 1. The middle section doesn't belong in your question. It really belongs in an answer, and it makes really no sense in the question. 2. Can you provide an example? I'm not seeing why this is even a problem. If the challenge asks for anything to be given, then of course an answer can output it with the normal output method? \$\endgroup\$ – Rɪᴋᴇʀ Jan 5 '18 at 16:32
  • 1
    \$\begingroup\$ @Riker Example. Although the OP specifically allow stdout error it then becomes unobservable if the printed content is "caused by an error". \$\endgroup\$ – user202729 Jan 5 '18 at 16:52
  • 2
    \$\begingroup\$ That's not really a problem IMO. The answer can just specify which one it uses. \$\endgroup\$ – Rɪᴋᴇʀ Jan 5 '18 at 16:57
  • 1
    \$\begingroup\$ @Riker Those two programs are different, but the difference is unobservable. \$\endgroup\$ – user202729 Jan 5 '18 at 17:11
  • \$\begingroup\$ I see what you mean now. I think in this case, it doesn't really matter. It's highly unlikely its shorter to generate the error than it is to actually error. \$\endgroup\$ – Rɪᴋᴇʀ Jan 5 '18 at 17:22
  • \$\begingroup\$ The question needs some serious clarification to specify what you mean. \$\endgroup\$ – Rɪᴋᴇʀ Jan 5 '18 at 17:51
  • \$\begingroup\$ I've tried to address ^, let me know how I did. \$\endgroup\$ – Rɪᴋᴇʀ Jan 5 '18 at 17:58
4
\$\begingroup\$

Authors ought to specify what they mean by errors

No definition we decide on as a community is going to fit every challenge involving an error. STDERR is a pretty good definition but often times authors are going to want to use something different, so we should let authors decide.

If you see a question that just says some thing like "Throw an error" you should ask for clarification. If they don't clarify with a concrete definition of what they mean by error, then that question is unclear and should be closed.

\$\endgroup\$
  • 1
    \$\begingroup\$ I think throwing an error is clear enough for (almost?) all languages. The way a normal error presents itself in a given language should be the way to throw an error when needed. \$\endgroup\$ – Adám Jan 10 '18 at 14:58
  • \$\begingroup\$ @Adám That looks like a separate answer to me. \$\endgroup\$ – Erik the Outgolfer Jan 10 '18 at 14:59
  • \$\begingroup\$ @EriktheOutgolfer I already posted that. \$\endgroup\$ – Adám Jan 10 '18 at 15:00
  • 1
    \$\begingroup\$ @Adám I'm not sure I understand your point. It seems to me that you are saying something along the lines of "an error is something that is output in the same way an error normally is". (which is perhaps a more nuanced version of "an error is an error"?) I'm also not very sure of how this relates to my answer rather than the topic as a whole. You may need to spell these things out for me. \$\endgroup\$ – Wheat Wizard Jan 10 '18 at 15:09
-2
\$\begingroup\$

Yes.

IMHO, it doesn't really matter. It's unlikely that it's shorter to fake-generate the error (via printing an error message) than it is to actually generate the error.

In addition, most questions don't specify an exact error to generate, and most languages allow the 3-byte 1/0 snippet to error out.

AFAICT, there's no good reason to force errors to STDERR.

What about for generating a specific error message, instead of a generic "error"?

If the challenge requests a specific error message, then that's more of a challenge, but with a possible golfing trick of generating the error. In that case, I think it falls under the standard I/O rules, which allow the answerer to choose STDERR or STDOUT.

\$\endgroup\$
  • 1
    \$\begingroup\$ -1 How do you differentiate between print "Error" and print "ZeroDivisionError: integer division or modulo by zero", or even print "Success"? If we are going to define what an error is on this site, it needs to be an observable requirement. STDERR is a great, observable way to limit what is an error and what isn't. \$\endgroup\$ – Nathan Merrill Jan 5 '18 at 18:22
  • \$\begingroup\$ @NathanMerrill then what about langs like mathematica, where STDERR isn't a thing? \$\endgroup\$ – Rɪᴋᴇʀ Jan 5 '18 at 18:26
  • 1
    \$\begingroup\$ Tough luck? We don't require that any language can be used for any challenge. \$\endgroup\$ – Nathan Merrill Jan 5 '18 at 18:29
  • \$\begingroup\$ @NathanMerrill With some languages, you can just as easily print anything to STDERR as you can to STDOUT. \$\endgroup\$ – Steadybox Jan 5 '18 at 19:44
  • 1
    \$\begingroup\$ @Steadybox Perfect. My goal here isn't to make it difficult to error out, but that we need some observable way for us to say "This is an error". \$\endgroup\$ – Nathan Merrill Jan 5 '18 at 20:12
  • 2
    \$\begingroup\$ @NathanMerrill I'm just saying that "any output to STDERR" might not be a very good definition for an error. \$\endgroup\$ – Steadybox Jan 5 '18 at 20:17
  • \$\begingroup\$ @NathanMerrill STDERR is a thing in Mathematica \$\endgroup\$ – user202729 Jan 6 '18 at 3:01
  • \$\begingroup\$ @user202729 I'm thinking that you pinged the wrong user :) \$\endgroup\$ – Nathan Merrill Jan 6 '18 at 4:40
-3
\$\begingroup\$

Output to STDOUT should only be allowed if that is the language's default for errors

I think throwing an error is clear enough for (almost?) all languages. The way a normal error presents itself in a given language should be the way to throw an error when needed.

\$\endgroup\$
  • \$\begingroup\$ Assuming that we are already capable of determining what is an error and what is not, what does default mean? For example errors in some languages may go to either STDOUT or STDERR. A segfault in C will go to STDOUT while other types of error will go to STDERR. Which is the default in these cases? \$\endgroup\$ – Wheat Wizard Jan 10 '18 at 15:23

You must log in to answer this question.

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