golang-error-handling
Go のエラーの作り方・包み方・調べ方・記録の仕方を、慣用の作法で書かせ、見直させる。エラーは記録するか返すかのどちらか一度だけ、という決まりを軸に、集約の道具で扱いやすい記録の形まで整えさせる
npx skills add samber/cc-skills-golang/golang-error-handling入れる前にこのスキルがすること・注意点・SKILL.md の原文を確かめてください。解析は安全性の判定ではありません。
- インストール
- 44,385
- 実用度
- 9
- GitHub star
- 3,806
- 最終更新
- 2026/11/1
頼み方の例
そのままコピーして使えますgolang-error-handlingスキルを使って、このパッケージのエラーの扱いを点検してください。握りつぶし、記録して返す二重の扱い、文脈の無い返し方、panic の使いすぎを一覧にし、直し方の案を添えてください。コードはまだ書き換えないでください。
対象のファイルや状況は、ご自身の作業に合わせて置き換えてください。
このスキルがすること
SKILL.md の記述から機械的に抽出- 外部通信・シェル実行・ファイル操作の記述は見つかりませんでした
これは安全性の判定ではありません。 SKILL.md にそう書かれているという事実だけを並べています。実際に問題があるかは使い方と文脈で決まるため、当サイトでは断定しません。導入前に SKILL.md の原文を確認してください。
SKILL.md の規模
いつ使うか
Go のコードで、エラーを作る・包む・調べる・記録するときに効きます。samber が公開する、Go 専用のスキル集の 1 本です。
本文はエージェントに「Go の信頼性の技術者」として振る舞わせ、すべてのエラーを、処理するか文脈を添えて上へ渡すべき出来事として扱わせます。黙って消える失敗と、同じ記録の重複を、同じくらい受け入れられないものとしています。*.go のファイルを扱うときに読み込まれる設定です。
- 冒頭の決まりの一覧
- 15 項目
- 進め方（書く・見る・点検）
- 3 つ
- 点検で分ける観点
- 5 つ
- 同梱ファイル（2026-10-23 時点）
- 4 件
3 つの進め方
- 書く新しいエラーの扱いを書く。決まりを順に当て、必要なら隣のコードの握りつぶしや二重の扱いを裏で探させる
- 見るプルリクエストの差分に絞り、握りつぶし、文脈の無い包み方、記録して返す組、panic の誤用を見る
- 点検するコード全体を、最大 5 つの下位のエージェントに観点ごとに分けて並行で調べ、結果をまとめる
点検で分ける 5 つの観点は、エラーの作り方、包み方、一度だけ扱う決まり、panic と recover、構造を持った記録です。
冒頭の決まり 15 項目の主なもの
返されたエラーは必ず確かめ、_ で捨てない。fmt.Errorf("{文脈}: %w", err) で文脈を添えて包む。エラーの文字列は小文字で始め、末尾に句読点を付けない、などが並びます。
同じ印のエラー（番兵のエラー）との一致は errors.Is、型の取り出しは errors.As か Go 1.26 以降の errors.AsType で行い、直接の比較や素の型の判定はしない決まりです。独立した複数のエラーは、Go 1.20 以降の errors.Join でまとめます。
包むか、切るか
モジュールの内側では %w で包んで連なりを保ち、公開の API などの境目では %v にして連なりを切ります。呼び出す側が内部のエラーの型に頼れないようにするためです。
包みを重ねると、各層が前置きを足し、「注文を作る: カードに請求する: 決済の窓口につなぐ: 接続を拒まれた」のように読める連なりになる、と同梱の資料は示しています。自分で作るエラーの型が別のエラーを抱えるなら、Unwrap() を実装して errors.Is と errors.As がたどれるようにします。
どの作り方を選ぶか
同梱の資料の表は、場面ごとに 4 つの作り方を分けています。
| 場面 | 作り方 |
|---|---|
| 呼び出す側が特定の状態と一致を見たい | 番兵のエラー（パッケージの変数に errors.New） |
| 呼び出す側が構造を持った値を取り出したい | 自分で作るエラーの型 |
| 知らせるだけで一致を見ない | fmt.Errorf か errors.New |
| スタックの記録・利用者の文脈・属性が要る | samber/oops |
使わないほうがいいとき
samber/oops や slog の細部を知りたいとき
本文は、samber/oops の API の全体は golang-samber-oops に、slog の扱いの仕組みの周辺は golang-samber-slog に回しています。記録の設定・記録の重さの段階・HTTP の要求の記録の仕組みも、golang-observability の範囲です。
決まりの一覧には「HTTP の要求を構造を持った仕組みで記録する」という項目がありますが、同梱の資料の記録の節は、詳しくは golang-observability を見よ、の 1 行だけです。このスキル 1 本では、記録の仕組みの組み立てまでは書かれていません。
nil のエラーの落とし穴や、名前の付け方を知りたいとき
interface に包まれた nil の比較の落とし穴は golang-safety、ErrNotFound や PathError のような名前の付け方は golang-naming に回されています。
会社の決まりがすでにあるとき
本文は、自分を「共同体の既定」と位置づけ、明示的に置き換える会社のスキルがあればそちらを優先する、と書いています。テストの書き方なら、同じスキル集の golang-testing が受け持ちます。
注意点
書かれているコマンドと道具
frontmatter の allowed-tools には、Read・Edit・Write・Glob・Grep、Bash(go:*)・Bash(golangci-lint:*)・Bash(git:*)、下位のエージェント（Agent）が並びます。allowed-tools は道具を絞る設定ではなく、呼ばれた回に確認なしで使ってよい道具を宣言するものです。ほかの道具も使えます。
前提として要る実行ファイルは go だけです。本文と同梱の資料には、外へ通信する手順はありません。
記録するか返すか、どちらか一度だけ
利用者に見せる文と、技術の詳細も分けます。内部のエラーを分かりやすい言葉に置き換えて見せ、技術の詳細は別に記録する、という決まりです。
記録の文は変えない
Datadog・Loki・Sentry のような集約の道具は、記録の文やエラーの指紋でまとめることが多い、と同梱の資料は書いています。文に利用者の ID や行の番号のような変わる値を入れると、組み合わせごとに別のまとまりができ、画面が散らかって通知も壊れます。
そのため、記録の文は固定し、ID・経路・行の番号・数は構造を持った属性として添えます。fmt.Errorf("fetching user: %w", err) のような変わらない前置きは問題ない、とも書かれています。
panic は回復できない状態だけ
panic は、プログラムの書き間違い、起こりえない状態、壊れた前提のためだけに使い、通信の時間切れやファイルが無いといった想定内の失敗には使わない決まりです。
recover は、HTTP の受け手や作業用の goroutine のような境目で、defer の中に置きます。1 つの panic で処理全体が落ちないようにするためです。
例の一部は公開元の作ったライブラリを使う
決まりの 11 番目は、スタックの記録や利用者・契約者の文脈、構造を持った属性が要る本番のエラーに samber/oops を使え、というものです。samber/oops は、このスキル集の公開元と同じ samber のライブラリで、外部の依存として取り込むことになります。
同梱の資料は、標準のライブラリだけで同じことをする書き方も並べています。依存を増やしたくないなら、そちらの書き方を指定してください。
下位のエージェントを並べると費用が増える
全体を点検するときは、最大 5 つの下位のエージェントを並行で動かす決まりです。本文は、Claude Code では ultracode で複数のエージェントの進め方を明示的に選ぶよう書いています。大きなコードほど、使う量が増えることを見込んでください。
インストール数の推移
日次で記録9月18日 〜 11月7日（40日分）
インストール数と 1 日あたりの増加は Skillselion が に集計した値です。上流の更新は数日おきなので、前日比ではありません。GitHub star と最終更新は に GitHub から取得しました。
併用すると強いスキル
systematic-debugging
根本原因を突き止めるまで修正させない。3 回直して駄目なら設計を疑わせる
golang-code-style
Go のコードを、整形の道具では決まらない読みやすさの決まりで書かせ、見直させる。行の折り方、変数の宣言の形、早めに返す書き方、引数の数と順、値か参照かの選び方まで、人の判断が要るところを揃えさせる
golang-testing
Go のテストを、表で並べる書き方・並列化・ファジング・goroutine の漏れの検出・結合テストの分離まで含めて書かせ、見直させる。新しく書く・差分を見る・全体を点検する・落ちる原因を追うの 4 つの進め方を使い分けさせる
よくある質問
同梱ファイルには何がありますか
references/ に、エラーの作り方、包み方と調べ方、扱い方と記録の 3 本の資料があります。もう 1 つは evals/evals.json で、HTTP の仲介の処理の連なりや CSV の読み込みなど、エラーの扱いを試す 12 の課題が入っています（2026-10-23 時点）。
errors.As と errors.AsType はどちらを使えばいいですか
本文は、Go 1.26 以降で、取り出す型 T が error を実装しているなら errors.AsType[T](err) を勧めています。Go 1.26 より前か、取り出す先が error 以外の interface なら errors.As(err, &target) を使います。どちらも包まれた連なりをたどる点は同じで、素の型の判定はたどれません。
errors.Join でまとめたエラーも errors.Is で調べられますか
調べられます。同梱の資料は、errors.Join でまとめたエラーに対して、中のそれぞれのエラーが errors.Is で一致することを例で示しています。複数の項目の入力の確かめや、複数の閉じる処理の失敗をまとめる使い方が載っています。まとめるものが無ければ nil が返ります。
slog を使うのは必須ですか
本文の決まりでは、エラーの記録には fmt.Println や log.Printf ではなく、Go 1.21 以降の slog を使うべき（SHOULD）とされています。必須（MUST）の項目ではありません。記録の重さを段階で示すことも決まりの 1 つです。