Functions throwing exceptions: an exception to the rules?

Question

I'm seeking greater clarity around whether we currently allow functions to throw exceptions, and if so, under what circumstances. There seem to be contradictory posts on this topic—several highly upvoted and all with positive scores—scattered across Meta.

No exceptions

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.

The quote above comes from the accepted answer (+26/-3) to Should submissions be allowed to exit with an error?. That answer, together with the accepted answer (+44/-8) to Do function submissions have to be reusable?, proposes the following rules for function submissions (as I understand them):

• Functions must be reusable arbitrarily often.
• Any error during a function call that terminates the call, but not the enclosing program, is permissible.
• Any error during a function call that either (i) unconditionally terminates the program or (ii) terminates the program unless specially handled in the external scope (e.g. wrapped in the language's equivalent of Python's try/catch block) is not permissible.
• If an exception is thrown during function definition (i.e. before the function can be called), the language's equivalent of a try/catch block must be included in the byte count.

The accepted answer (+20/0) to What are our rules about additional code accompanying function submissions? further clarifies that

• Once a function has been defined, calls to that function must not rely on any additional code.

I interpret these posts to state unequivocally that functions may not throw exceptions, even if those exceptions could be caught.

Except...

More recently, three answers to Default for Code Golf: Input/Output methods explicitly refer to functions throwing exceptions. Their titles are fairly self-explanatory:

• Functions may return a boolean value via the presence or absence of an error/exception (+44/-13)
• Functions may output via throwing the output value as an exception, if it could be caught, and read by the code catching the exception (+7/0)
• Functions may generate different output via different exceptions if they could be caught using different code (+6/0)

The first of these rules also appears to have been repeated under Default policy for ouput in decision problems:

• A function submission may reject inputs by raise an exception (+4/0)

These defaults would seem to allow functions to throw exceptions under certain circumstances.

Questions

I can see a few possible explanations for the apparent contradiction:

• An old consensus banning functions from throwing exceptions has been superseded (or partially superseded) by a newer consensus allowing this.
• There is, in fact, no consensus.
• I've failed to grasp a meaningful (but possibly subtle) distinction between the scenarios covered by the cited groups of posts.

My questions:

1. Has a blanket ban on functions throwing exceptions gone out the window?
2. If so, are there cases in which throwing an exception from a function is still considered unacceptable, and if so, why? A non-trivial example that falls outside the scope of the 'default I/O' posts cited above is this solution to Complete a sequence using its distances. The function relies on an exception to terminate an indefinitely repeated process, but may be called arbitrarily often by appending a rescue clause.
3. If functions are allowed to throw exceptions (whether generally or only under specific circumstances), to what extent are the rules concerning function reusability and accompanying code still in force?

Answer 1

Functions throwing exceptions should be allowed

based on this brief chat conversation

As long as the exceptions can be caught, this seems like a perfectly legitimate way of producing output or stopping the function's execution. We allow things like await f() or f(1)(), so try {f()} catch (x) {...} seems perfectly reasonable.

I wouldn't consider these functions to be non-reusable. I mean, f(1)(2) also isn't reusable if you ignore how it's supposed to be called and cause an error by doing something like f(1, 2), but we ignore that since it's assumed the function is called the correct way (with a try/catch if exceptions can be used for output).

This allows for more interesting possibilities, like quickly returning a value in a recursive solution as mentioned by l4m2, or compactly indicating things like invalid input for relevant challenges.

The only situations this shouldn't be allowed, aside from when the challenge author explicitly disallows it, is if the answer uses exceptions output, but then also ignores the limitations of the machine when that can also cause an exception. E.g., relying on a maximum call stack error for one case, but also assuming that the stack can be arbitrarily large in another part of the solution.