Proposal:
concurrent.futures.Executor.submit() implementations currently raise a generic RuntimeError when work is submitted after executor shutdown. For example, ThreadPoolExecutor.submit() raises one of these messages:
RuntimeError("cannot schedule new futures after shutdown")
RuntimeError("cannot schedule new futures after interpreter shutdown")
This makes it difficult for callers to distinguish expected executor lifecycle failures from unrelated RuntimeErrors without matching exception message strings:
try:
future = executor.submit(fn)
except RuntimeError as exc:
if str(exc) in {
"cannot schedule new futures after shutdown",
"cannot schedule new futures after interpreter shutdown",
}:
handle_executor_shutdown(exc)
else:
raise
It would be useful to expose a typed exception for this condition, for example:
class ExecutorShutdownError(RuntimeError):
pass
Then executor implementations could raise ExecutorShutdownError for explicit shutdown and interpreter-shutdown submission failures. Because it would subclass RuntimeError, existing callers catching RuntimeError would remain compatible, while callers that need precise handling could avoid brittle string matching:
try:
future = executor.submit(fn)
except concurrent.futures.ExecutorShutdownError:
handle_executor_shutdown()
This would mirror the existing benefit of typed executor failures such as BrokenExecutor, where callers can distinguish executor state from arbitrary runtime failures without inspecting exception text.
Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
None. I searched existing CPython issues for ExecutorShutdownError, cannot schedule new futures after shutdown, cannot schedule new futures after interpreter shutdown, and related concurrent.futures RuntimeError shutdown exception type wording. I found issues about shutdown behavior itself, but not this typed-exception API request.
Proposal:
concurrent.futures.Executor.submit()implementations currently raise a genericRuntimeErrorwhen work is submitted after executor shutdown. For example,ThreadPoolExecutor.submit()raises one of these messages:This makes it difficult for callers to distinguish expected executor lifecycle failures from unrelated
RuntimeErrors without matching exception message strings:It would be useful to expose a typed exception for this condition, for example:
Then executor implementations could raise
ExecutorShutdownErrorfor explicit shutdown and interpreter-shutdown submission failures. Because it would subclassRuntimeError, existing callers catchingRuntimeErrorwould remain compatible, while callers that need precise handling could avoid brittle string matching:This would mirror the existing benefit of typed executor failures such as
BrokenExecutor, where callers can distinguish executor state from arbitrary runtime failures without inspecting exception text.Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
None. I searched existing CPython issues for
ExecutorShutdownError,cannot schedule new futures after shutdown,cannot schedule new futures after interpreter shutdown, and relatedconcurrent.futures RuntimeError shutdown exception typewording. I found issues about shutdown behavior itself, but not this typed-exception API request.