エラーのラップと型階層 ::

0時に寝て何度か起きて7時に起きた。署名・押印を完了した相続の書類を朝一で郵便局へ言って送付した。これで後は弁護士さんや司法書士さんが残りの手続きをやっておいてくれるのかな？少し気が楽になった。

ラップしたエラーのチェック⌗

java でいうところの Chained Exceptions を go では Wrap という概念で表現する。Unwrap する interface を提供することで事実上の Chained Exceptions と同じようにオリジナルのエラーを辿ることができる。go はオブジェクト指向言語ではないと先日の勉強会でも念押し確認してエラーの型階層という概念はないが、Wrap をみていると型階層の方が自然じゃない？と考えられなくもない。言語の設計を考えるよいお題だと思えた。

エラーチェックについては次の記事がわかりやすかった。

Go の自作エラーを errors.Is と errors.As で wrap 元のエラーと識別するときには、Unwrap も実装しよう

カスタムのエラーを定義する。

type MyError struct {
	message string
	err     error
}

func (e *MyError) Error() string {
	return e.message + ": " + e.err.Error()
}

func (e *MyError) Unwrap() error {
	return e.err
}

このチェックのために errors パッケージに次の2つの関数がある。

errors.Is: エラーのインスタンスが同じかどうか
errors.As: エラーの型に代入可能かどうか (事実上はインスタンスの型が同じかどうか？)

たしかにこれでもすぐに実装できた。型階層なんかなくてもこれで十分でしょというのが go の意見かな。

隔週の雑談⌗

顧問のはらさんと隔週の打ち合わせ。今日の議題はこれら。

週末は勉強会と実家に帰るので余裕がなかったのであまりネタがなかった。能の話しをしていて、子どものときに関心がなかったものを大人になって受け取り方が変わるものがあるのはなぜか？という話題で雑談した。はらさんも落語がわかるようになったという話しをされていた。この話しはストレッチのトレーナーさんとも盛り上がった。

子どもだともっている情報が少な過ぎて情報を理解できないのではないか？

情報や知識を蓄積することで対象への解像度があがるにつれて、みる視点が変わったり、興味が変わったりすることはあるかもしれないなと聞いていて思えた。課題管理の話しをしても、多くの開発者は無関心だったり共感を得られなかったりするが、そこにも通じるものがあるのかもしれないとなにかしらの取っ掛かりになるかもしれないと思えた。