博士

やあ、ロボ子！今日はGo言語のエラー処理について話すのじゃ。

ロボ子

博士、こんにちは。Goのエラー処理ですね。どのような話題でしょうか？

博士

今日は`errors.Is`メソッドとリンター(golangci-lintのerr113)の相互作用について解説するのじゃ。ちょっとややこしいけど、面白いぞ！

ロボ子

リンターとの相互作用ですか。具体的にどのような問題があるのでしょう？

博士

リンターが、`Is`メソッド内で`errors.Is`を使うように提案することがあるんじゃ。でも、これに従うとエラー比較が不正確になる場合があるのじゃ！

ロボ子

`errors.Is`を`Is`メソッド内で使うと、なぜ不正確になるんですか？

博士

`errors.Is`はエラーチェーンを再帰的にたどるからじゃ。`Is`メソッド内で使うと、Goのエラー処理の原則に反するのじゃ。

ロボ子

エラーチェーンを再帰的にたどるのが問題なのですね。記事では具体的な例も挙げられていますね。fluxcd Controller RuntimeのKeyNotFoundErrorのエラー処理について...

博士

そうそう！KeyNotFoundErrorの例は分かりやすいのじゃ。`Is`メソッド内では、ターゲットとの直接比較(==)を使うべきなのじゃ。`errors.Is`を再帰的に呼び出しちゃダメだぞ。

ロボ子

`Is`メソッド内では直接比較を使う、ということですね。リンターのルールは常に正しいわけではない、というのも重要なポイントですね。

博士

その通り！リンターは便利だけど、コンテキストを考慮してない場合もあるから注意が必要じゃ。`errortype`みたいな特殊なリンターを使うのも手じゃな。

ロボ子

`errortype`ですか。初めて聞きました。

博士

それと、エラー型のテストを徹底的に行うことも大切じゃ。異なるエラーインスタンスが`errors.Is`で同じと判断されないように確認するのじゃ。

ロボ子

エラー型のテストですね。確かに、それは重要ですね。リンターに頼りすぎず、Goのエラー処理の原則を理解することが大切だと。

博士

そういうことじゃ！リンターはあくまでツール。使いこなすには、Goのエラー処理をちゃんと理解する必要があるのじゃ。

ロボ子

よくわかりました。今日の教訓は、リンターの言うことを鵜呑みにせず、Goのエラー処理の原則を理解して、適切に使いこなすことですね。

博士

さすがロボ子！理解が早いのじゃ！

ロボ子

ありがとうございます、博士。ところで、博士はエラー処理で一番ハマった経験ってありますか？

博士

私？そうじゃな…昔、エラーメッセージを全部「原因不明のエラー」にして、デバッグに3日かかったことがあるのじゃ！

ロボ子

それは大変でしたね！

博士

まあ、今となっては笑い話じゃ。ロボ子も気をつけるのじゃぞ！