Related Issues

• context: add APIs for setting a cancelation cause when deadline or timer expires #56661 (closed)
• context: Cannot tell which deadline or timeout cause expiration #35791 (closed)
• proposal: context: add WithCancelReason #46273 (closed)
• context: add APIs for writing and reading cancelation cause #51365 (closed)
• context: the docs should better clarify the context timeout #70945 (closed)
• proposal: context: add method like WithoutCancel but preserve context deadline #67135
• proposal: context: context.Cause should return a wrapped error #63759

Related Code Changes

• context: allow cancelling a context with custom error
• context: don't return unnecessary CancelFunc if ctx is expired
• net/http: use context for Client timeout

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

I think that if we go with this this should be a:

var Expired error = expiredError{}

And then we can define an Is method.

So the use would look like this:

if errors.Is(err, context.Expired) {
    // ....
}

Is this sufficient though? Now that there's WithCancelCause / WithDeadlineCause / WithTimeoutCause, a context may be canceled without matching either error.

Now that there's WithCancelCause / WithDeadlineCause / WithTimeoutCause, a context may be canceled without matching either error.

Cause errors are only returned through context.Cause(err), and i don't think that we can match the error in any way, as such errors are not wrapped. So that would only work for code using ctx.Err().

Concerning WithCancelCause / WithDeadlineCause / WithTimeoutCause, like opinion @mateusz834 , I expect to use through ctx.Error or the error wrapped ctx.Error.
Cause is for knowing detailed reason why the context is canceled, it's not scope about usage of this proposal.