うーん、 CancellationError は isCancelled == true のときに Task.checkCancellation が投げるエラーというだけで、キャンセルされたときに throw されるエラーは CancellationError とは限らないという仕様なのかな？ catch let error as CancellationError でキャンセルをチェックするのではなく、 catch 節の中で Task.isCancelled でチェックするのが正しい？ (edited)

10:49 AM

URLSession の data(from:) がどこで実装されてるのか見つからない・・・。

10:56 AM

Conventionally, most functions that check for cancellation report it by throwing CancellationError()

だから必ずしも CancellationError を throw しなくても良い？でも

Operations running synchronously as part of the task can check this flag and are conventionally expected to throw a CancellationError

とあるので、 CancellationError を throw することが期待されている？ URLSession.data(from:) が cancel 時に CancellationError を throw しないのはお行儀が悪い？ https://github.com/apple/swift-evolution/blob/main/proposals/0304-structured-concurrency.md#cancellation (edited)

11:00 AM

For tasks that would prefer to immediately exit with a thrown error on cancellation, the task API provides a common error type, CancellationError, to communicate that the task was cancelled.

この communicate の温度感もわからないな。キャンセルされたことを CancellationError として検出できるように、くらいの意味まで持つならキャンセル時に独自のエラーを throw するのではなく CancellationError を throw すべきとなりそうだけど。

11:02 AM

いずれにせよ、キャンセル時にどんなエラーが投げられるかは実装依存だから、 API 利用側でキャンセルされたかを区別する必要がある場合、

do { try await foo() } catch let error as CancellationError { // キャンセル時の処理 } catch { // エラーハンドリング }

とするよりも

do { try await foo() } catch { if Task.isCancelled { // キャンセル時の処理 } else { // エラーハンドリング } }

がベストプラクティス？ (edited)