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.
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
catchblock) 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
catchblock 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.
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:
These defaults would seem to allow functions to throw exceptions under certain circumstances.
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.
- Has a blanket ban on functions throwing exceptions gone out the window?
- 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
- 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?