There are a few different issues and cases to be considered here. I think most of what I wrote below is based on the unwritten rules we're currently applying (as far as I'm aware of them). But a few things are also my own opinion, so let the votes show what you think.
As far as I know, this is common practice. What goes to STDERR also depends on error/warning levels and such, so I guess it's easiest to just say that STDERR can be ignored completely, as long as STDOUT has the required output (or the required side effects happen or whatever the challenge asks for).
Throwing Errors and Exceptions
I think this really depends on whether the submissions is a full program, REPL snippet or a function, and in the latter case whether the error happens during function definition or function call.
I think terminating with an error or an uncaught exception is fine here, as long as it doesn't produce stray output to STDOUT. Under the premise that we're ignoring STDERR, a program terminating with an error still does the job.
As long as these don't break stuff so badly that you have to restart the REPL, I think they should be treated the same as full programs. If they produce the right output or side effects, barring STDERR, aborting with an error or exception is fine.
Errors during Function Definition
(By this I mean "at the time the function is defined". I.e. if the code snippet provided in the submission throws an error before ever calling the function.)
This is the example mentioned in the question. I would say this depends on whether REPL snippets are valid submissions to the challenge (which they are not by default).
- If REPL snippets are valid, I would treat the function definition just as a REPL snippet and the above rules apply.
- If REPL snippets are not valid (the default), I think this should not be allowed. If an error is thrown during function definition, this renders the function useless because it can never be called. If an exception is thrown that could be caught, the necessary try-catch block has to be included in the byte count.
Errors during Function Call
Again, if the challenge also allows REPL snippets, the REPL rules should apply.
Otherwise, I'm not sure. I would say it depends on whether the error would only abort the function call or the program. If it only aborts the function call that's fine. If it causes an error that aborts the entire program, or it throws an exception (even if it could be caught!), then I think this should not be allowed. If people answer with functions, they should take into account that the purpose of functions is to reuse them without restarting the program. If you really want to throw an error, answer with a full program.
In any case, answers should state explicitly if they are throwing errors. It's part of their interface, and we usually expect good answers to state I/O details as well.
And, as usual, any challenge author may override any of these defaults if they so wish.