Problems with CoroutineExceptionHandler as an extension point

Language Design
1
  1. CoroutineExceptionHandler doesn’t fit nicely in the handleCoroutineException() logic: when CEH is present in the context, hCE doesn’t do the default logic, thus forcing the implementation to do it — like ignoring CancelledException, trying to cancel the job and calling the registered CEH services. This is problematic because the implementors are now required to watch changes in hCE’s behaviour changes and update the implementation accordingly.
  2. OK, one can simply call handleCoroutineException(context.minusKey(key), ...), but it does something that not everyone wants to do, namely directly calls the current thread’s uncaught exception handler. What’s the logic behind this? First, this exception is handled, so it’s not “uncaught” to begin with. Second, one would assume that this is the last resort when the stack is unwound to the bottom of the stack frame, which isn’t the case here. Finally, it causes double-logging if the exception, because CEH implementation might want to log (or not to log!) the exception in their own way.

I’d actually propose to extract reusable logic from hCE, which would be everything it does now except for calling the CEH from the context and calling the uncaught exception handler.