Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Go1.20からサポートされるtree構造のerrの紹介と、treeを考慮した複数マッチができ...
Search
convto
June 02, 2023
Technology
0
1.2k
Go1.20からサポートされるtree構造のerrの紹介と、treeを考慮した複数マッチができるライブラリを作った話/introduction of tree structure err added since go 1_20
convto
June 02, 2023
Tweet
Share
More Decks by convto
See All by convto
MCPと認可まわりの話 / mcp_and_authorization
convto
2
600
バクラクの認証基盤の成長と現在地 / bakuraku-authn-platform
convto
4
1.3k
gob バイナリが Go バージョンによって 出力が変わることについて調べてみた / Investigating How gob Binary Output Changes Across Go Versions
convto
0
130
Go 関連の個人的おもしろCVE 5選 / my favorite go cve
convto
3
470
バイナリを眺めてわかる gob encoding の仕様と性質、適切な使い方 / understanding gob encoding
convto
6
2.9k
みんなでたのしむ math/big / i love math big
convto
0
280
Go1.22からの疑似乱数生成器について/go-122-pseudo-random-generator
convto
2
820
byte列のbit表現を得るencodingライブラリ作った
convto
1
1.2k
Go runtimeの歩き方/how to follow go runtime function
convto
1
1k
Other Decks in Technology
See All in Technology
生成AI活用のROI、どう測る? DMM.com 開発責任者から学ぶ「AI効果検証のノウハウ」 / ROI of AI
i35_267
4
140
RAID6 を楔形文字で組んで現代人を怖がらせましょう(実装編)
mimifuwa
0
210
モノレポにおけるエラー管理 ~Runbook自動生成とチームメンションの最適化
biwashi
0
480
datadog-distribution-of-opentelemetry-collector-intro
tetsuya28
0
210
ABEMAにおける 生成AI活用の現在地 / The Current Status of Generative AI at ABEMA
dekatotoro
0
580
[OCI Technical Deep Dive] OCIで生成AIを活用するためのソリューション解説(2025年8月5日開催)
oracle4engineer
PRO
0
130
あなたの知らない OneDrive
murachiakira
0
200
意志の力が9割。アニメから学ぶAI時代のこれから。
endohizumi
1
110
認知戦の理解と、市民としての対抗策
hogehuga
0
170
信頼できる開発プラットフォームをどう作るか?-Governance as Codeと継続的監視/フィードバックが導くPlatform Engineeringの進め方
yuriemori
1
360
2025新卒研修・Webアプリケーションセキュリティ #弁護士ドットコム
bengo4com
3
10k
Preferred Networks (PFN) とLLM Post-Training チームの紹介 / 第4回 関東Kaggler会 スポンサーセッション
pfn
PRO
1
120
Featured
See All Featured
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Become a Pro
speakerdeck
PRO
29
5.5k
Designing Experiences People Love
moore
142
24k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.1k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
890
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Intergalactic Javascript Robots from Outer Space
tanoku
272
27k
A Modern Web Designer's Workflow
chriscoyier
695
190k
Mobile First: as difficult as doing things right
swwweet
223
9.9k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Transcript
Go1.20から追加されたtree構造のerrの紹介と、 treeを考慮した複数マッチができる ライブラリを作った話 2023/06/02(金) Go Conference 2023 Online
自己紹介 @convto 株式会社LayerX所属 レイヤ低めの技術などに興味がありま す (ちなみにidの読みはこんぶとです)
contents - tree構造のerrの紹介 - proposalの議論などを おさらい - ありうるより高度なマッ チ要求 -
マッチ処理に関する実 験 - 実験の考察 - まとめ
contents - tree構造のerrの紹介 - proposalの議論などを おさらい - ありうるより高度なマッ チ要求 -
マッチ処理に関する実 験 - 実験の考察 - まとめ
Go1.20で複数errをwrapできるようになった https://tip.golang.org/doc/go1.20#errors
どういうことができるようになるか - こういうのができます - errをつくるときに複数errを合成できるように なり、マッチ処理でもそのような errが考慮さ れるようになる - あたらしいエラー構造とハンドリングが標準
パッケージでサポートされる!
いままでとなにがちがうか いままではこう - wrapされたerrの関係性は連結リスト的 - 枝分かれなし errA errB errC errD
いままではこう - wrapされたerrの関係性は連結リスト的 - 枝分かれなし これからはこう - errorをたどると枝分かれしてる可能性があ る -
tree構造 errA errB errC errD errA errB errC errD errC errD errD いままでとなにがちがうか
contents - tree構造のerrの紹介 - proposalの議論などを おさらい - ありうるより高度なマッ チ要求 -
マッチ処理に関する実 験 - 実験の考察 - まとめ
proposal
どういうproposal? - 複数errを一つのerrにしたい - `errors.Join()` や `fmt.Errorf()` で複数エラーの結合が可能に - 結合されたerrは
`Unwrap() []error` を実装していて取り出し可能 - 当初は `Split(error) []error` も提案されていた(後の議論でスコープ外に)
Is/Asの探索はどのようなデザインか - treeを深さ優先探索する - マッチしたものがあればそこで探索を打ち切り結果を返す - tree上のすべての枝がIs/Asにマッチすることを保証しない - 当時存在したエコシステム上のmultierrライブラリの一般的な挙動などを参考にし て設定
Is/Asの探索はどのようなデザインか errA errB errC errD errD errD errC
Is/Asの探索はどのようなデザインか errA errB errC errD errC errD errD
Is/Asの探索はどのようなデザインか errA errB errC errD errC errD errD
Is/Asの探索はどのようなデザインか errA errB errC errD errC errD errD
Is/Asの探索はどのようなデザインか errA errB errC errD errC errD errD
探索はどのようなデザインか - そんなに複雑でないし、あまり特別なこともし ていない - 枝分かれする探索部分のイメージをみると わかりやすいかも
proposal中のデザインに関連する議論をピックアップ - SplitなりWalkなりの探索APIは検討しなくてよい? - IsとかAsの意味合いがすこし変わっちゃうけどよい?
SplitなりWalkなりの探索APIは検討しなくてよい?
もともとはproposalにsplitが含まれていたが... - 探索自体は需要あるかもだけど、デザインについて議論の余地があった - `Split()` or `Walk()` とか - まずはmultierrのコアとなる仕様だけstdに入れよう!
- そうすればサードパーティで実験できるから、適切なデザインを探れる
IsとかAsの意味合いがすこし変わっちゃうけどよい?
どういうこと? - `Is()` はマッチした時点で探索をやめて true を返す - すべての分岐する枝で同一エラーかどうか を保証しない -
ある枝はtrueでも別の枝でfalseなとき一部 のエラーハンドリングで困るかも
どういうこと? - `Is()` はマッチした時点で探索をやめて true を返す - すべての分岐する枝で同一エラーかどうか を保証しない -
ある枝はtrueでも別の枝でfalseなとき一部 のエラーハンドリングで困るかも err crit err ignorable err こういうtreeだったとき cliterrを見逃してしまうかも
最終的には提案された仕様のままとなった - 一瞬 `Contains()` と `Is()` を区別したほうが良いかもみたいなこと言ってる人はい た - 既存multierr実装に合わせた形で仕様が提案されているので
`Is()` が最初のマッ チで探索を打ち切る挙動は一般的に期待されるものと一致してるだろうという結論
proposalふりかえりまとめ - tree構造を考慮したIs/Asが標準に追加 - 探索APIなどは今のところ未提供で、要実験 - マッチ処理も一部議論があったが提案通りの仕様で受け入れられた
contents - tree構造のerrの紹介 - proposalの議論などを おさらい - ありうるより高度なマッ チ要求 -
マッチ処理に関する実 験 - 実験の考察 - まとめ
デザインのおさらい - treeを深さ優先探索する - マッチしたものがあればそこで探索を打ち切り結果を返す - tree上のすべての枝がIs/Asにマッチすることを保証しない
考えられる問題は? - As/Isで意味合いが変わるので一部コードに問題がでるかも(ほぼ影響なし) - 構造が複雑になったので、文脈によってより高度なマッチ処理がしたくなるかも
考えられる問題は? - As/Isで意味合いが変わるので一部コードに問題がでるかも(ほぼ影響なし) - 構造が複雑になったので、文脈によってより高度なマッチ処理がしたくなるかも
考えられる問題は? - As/Isで意味合いが変わるので一部コードに問題がでるかも(ほぼ影響なし) - 構造が複雑になったので、文脈によってより高度なマッチ処理がしたくなるかも -> いまのAPIでうまく探索できるのかが課題
例1: より正確なIs()
errors.Is(errA, errD) errA errB errC errD errC errD errD
errors.Is(errA, errD) errA errB errC errD errC errD errD これがhitした時点で探索やめちゃう
errors.Is(errA, errD) errA errB errC errD errC errD errD これがhitした時点で探索やめちゃう
このへんの枝がhitしてなくても true返す
errors.Is(errA, errD) errA errB errD errD errD errE errE こういうときだけtrueかえしてほしい
例2: 全件抽出するAs()
errors.As(errA, errD) errA errB errC errD errC errD errD これがhitした時点でerrDを返す
errors.As(errA, errD) errA errB errC errD errC errD errD これがhitした時点でerrDを返す
このへんも返してほしくない?
errors.As(errA, errD) errA errB errC errD errC errD errD こういう結果を取り出したい
気になったので検証してみた - 例で上げた2つのマッチ処理を実装する - tree上のすべての枝に該当エラーが存在するか確認したい(例1) - tree上の該当エラーを枝などの関係性を問わずすべて抽出したい(例2) - いまの仕様で実装できるか試してみる
contents - tree構造のerrの紹介 - proposalの議論などを おさらい - ありうるより高度なマッ チ要求 -
マッチ処理に関する実 験 - 実験の考察 - まとめ
実験: より正確なIs()
errors.Is(errA, errD) errA errB errD errD errD errE errE こういうときだけtrueかえしてほしい
errors.Is(errA, errD) errA errB errC errD errD errE errE これはfalse
そもそも標準のIsってどう探索してるんだっけ? - `Unwrap() error` と `Unwrap() []error` をア サーションして探索 -
分岐してなければ剥がして終端でなければ loop - 分岐してれば各枝に再帰的に Is
枝が別れたら全部trueならtrueとすればよし - 分岐したときにマッチしない枝があれば false - ちなみに `Unwrap() []error` が len
0 となる ケースはいまの標準パッケージの実装では ないはず - いちおうproposalで空のケースが言及されて るのでみている
実験: 全件抽出するAs()
errors.As(errA, errD) errA errB errC errD errC errD errD こういう結果を取り出したい
どのようなものを作るか - Asのように具体的な型で取り出したい - `Scan[T any](err error, target T) (matched
[]T)` のようなデザインで考える - targetの具体的な型でmatchedを返せる - ただの抽出処理でありboolは返さないデザイン
Scan実装 - assignable or `As` 実装済みでマッチしたら 結果に追加 - 枝が分岐してなければ剥がして終端でなけ ればloop
- 枝が分岐してれば再帰的に Scan
contents - tree構造のerrの紹介 - proposalの議論などを おさらい - ありうるより高度なマッ チ要求 -
マッチ処理に関する実 験 - 実験の考察 - まとめ
ようはtreeへのマッチ処理で、さまざまな要求がありうる - tree上に該当エラーが1つ以上存在するか確認したい(go1.20のstd Isで提供され ているもの) - tree上に該当エラーが1つ以上存在するか確認して取り出したい(go1.20のstd As で提供されているもの) -
tree上のすべての枝に該当エラーが存在するか確認したい(例1) - tree上の該当エラーを枝などの関係性を問わずすべて抽出したい(例2)
ようはtreeへのマッチ処理で、さまざまな要求がありうる - tree上に該当エラーが1つ以上存在するか確認したい(go1.20のstd Isで提供され ているもの) - tree上に該当エラーが1つ以上存在するか確認して取り出したい(go1.20のstd As で提供されているもの) -
tree上のすべての枝に該当エラーが存在するか確認したい(例1) - tree上の該当エラーを枝などの関係性を問わずすべて抽出したい(例2) - こういうのもあるかも - 例1と例2を組み合わせて「マッチ判定は tree上のすべての要素が対象、 hitしたものはすべて抽出」 - etc..
実験前はこう思っていたけど... - 探索可能APIはほしいかも - joinしたerrをバラけさせるSplit()とか - errをバラして深さ優先探索して次の errを返すWalk()とか - 枝分かれする部分とそうじゃない部分を透過的に扱えると嬉しそう?
要求によっては連結リストと分岐部分を区別したいかも - 透過的な `Walk()` しちゃうと困るケースがあるかも - tree構造のerrは最近入ったばかりなので、エコシステム全体で実験を重ねていけ ばよりよい形が見えてくるのかも - そう考えるといまの
`Upwrap() error` or `Unwrap() []error` で素朴に型判定する 方針はよいバランス感覚かも?
contents - tree構造のerrの紹介 - proposalの議論などを おさらい - ありうるより高度なマッ チ要求 -
マッチ処理に関する実 験 - 実験の考察 - まとめ
まとめ - 標準パッケージにtree構造のエラーへのサポートが入った - これによりエラーハンドリングにあたらしい複雑さが生まれた - 標準パッケージでは共通してみんなが使いそうなマッチ処理がサポートされている - 高度なマッチ処理がやりたかったら探索できるAPIがある -
エコシステム全体で実験を重ねて知見をためればよりよい探索APIが見つかるかも - Goの簡素なエラー処理が個人的には好きなので、その性質を維持しつつよい方向 に整理されていくとよいですね!
ご清聴ありがとうございました