Replace TimeoutCancellationException with TimeoutException

[qwwdfsad]

In the current version of the library, withTimeout throws TimeoutCancellationException when a timeout was exceeded.

It can lead to very subtle errors, for example:

launch {
    val result = withTimeout(...) {
        // ... some computation ...
    }
    // process result
}

TimeoutCancellationException is CancellationException, thus is never reported.
But in the snippet above, it's likely to be a programmatic error. If it is expected to miss the deadline, then withTimeoutOrNull should be used explicitly.

My proposal is deprecation of TimeoutCancellationException and replacement with TimeoutException that is not CancellationException

[artbez]

Hi, @qwwdfsad !
My team and I also faced this problem. Do you have any expectations about the time this task will be solved?

[qwwdfsad]

Could you please elaborate on the problem you've faced?

[artbez]

Sure, we use withTimeout for restricting our inner functions with deadlines. So, any exceptions except CancellationException will be reported from our business logic code, but TimeoutCancellationException won’t. We want to parse such exceptions as others. And, as you said before, it would be possible if withTimeout threw TimeoutException instead of TimeoutCancellationException. Another case is when we use launch within coroutineScope. Exceded deadline in one job doesn't cancel other jobs. Of course, we can use our own custom launch which catches TimeoutCancellationException inside and throws TimeoutException or we can use withTimeoutOrNull. But, we'd like to know if you plan to change the behavior of withTimeout function.

Thank you!

[qwwdfsad]

The preliminary design decision is to deprecate withTimeout function with @LowPriorityInOverloadResolution and re-introduce it in the brand new package kotlinx.coroutines.time with the same name.

The change is now blocked by the IDE bug that doesn't replace a signature to the same name in a different package

[dkhalanskyjb]

This could be a good time to also avoid this behavior #1914 by checking at the end of the block if the coroutine was canceled and throwing in that case.

[qwwdfsad]

The same applies to the cancellation before withTimeout even start (that is also observed in #1914).

Historically, it was on par with withContext behaviour. Though the latter actively evolved (#962, #785, then #791), while withTimeout has been left as is. Its behaviour is clearly lagging behind what is expected from it by default and is worth changing.

It seems like we already have three potential changes in the function semantics:

• Exception type (more important, it's CE -> non-CE)
• Non-atomic cancellation (it also will help to get rid of all the hacks in our undispatchedResult and startUndispatchedOrReturnIgnoreTimeout) on completion
• Avoid entrance into the body of withTimeout if timeout already kicked in before the coroutine starts