#presentation #KotlinConf
Date: 2025-05-22
https://youtu.be/IUrA3mDSWZQ?si=55aV3GIuDCNdtusH
[こちら](https://resources.jetbrains.com/storage/products/kotlinconf-2025/may-22/Rich%20Errors%20in%20Kotlin%20_%20Michail%20Zarec%CC%8Censkij.pdf?_gl=1*1jfti2x*_gcl_au*MTY1NDI2NTQwMi4xNzUwNjg1NjY1*_ga*MjkwNzQzOTY3LjE3NTA2ODU2Njc.*_ga_9J976DJZ68*czE3NTA2ODU2NjQkbzEkZzEkdDE3NTA2ODU2ODAkajQ0JGwwJGgw) に資料も上がってる
## どんな動画
Kotlin 2.4 に導入される予定となってる Rich Errors という機能のセッション
この夏に KEEP もできるらしいのでできたら追記したい
## メモ
[](https://gyazo.com/f8fc73a4e549e1958fc1c56fc5e01144)
あくまでも Union ではなく特殊な意味論をもった Union とのことで `Main Actor` と `Error Attributes` に分かれている
個人的には、Kotlin には do 記法のように便利にモナドを扱うことができないので `Result` のようなラッパークラスで包まないというのは良い選択に思う (良いというか pragmatic に思う)
### syntax 周り
| [](https://gyazo.com/5fa1ef2d051cb8704ebca0dcdfb24748) | [](https://gyazo.com/1c95cd2d4cdc9bd66c731ce3a0d05e5b) |
| ----------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| | |
### 設計詳細
[](https://gyazo.com/7c2596535aa1bc30d0429211bd174b2c)
Nullable に対しての Safe Call 機能 ( `?.` ) のように Rich Errors にも利用することができる
Rich Errors の場合には、Error Attributes の型が Union として合成されていくような動きをしている
### ついでに得られる機能
| In place Tags | Optional Values |
| ----------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| [](https://gyazo.com/b083ec718d245770539c999a74e1ea51) | [](https://gyazo.com/ca987094e1e1cc6bb2b59d007fc96e28) |
| インラインで Rich Error の型を使うことができるので Union っぽいことが例外とは関係なくできる | null で無理くり実現するのではなく Optional で値がないかもしれない状況を型で表現できるようになる |
## 感想
- 上でも書いたけれど非常に Pragmatic な機能だなという感じがした
- 昨今 `Either` とかを真似する言語も多い中でかなり利用者に寄ったスタンスであることは間違いないように見える
- 今後も `error enum class` が入るかもとか今後の改善にも触れていたので引き続き watch していきたい
- 一方で `Main Actor | Error Attributes 1 | Error Attributes 2` という型の表記は、例えば safe call で合成する際には暗黙的に `Main Actor` の型に親子関係があることを期待していたりするのでもっといい表記がなかったか? (これだというのは思いつかないけれど) というのだけ気になる
```
fun doSomething(): MainActor errors Error1, Error2 { }
// とか
fun doSomething(): Result<MainActor | Error1, Error2> { }
// 実際には Rich Errors のように展開されてコンパイラからは見えるなど
```