観察
_ := で error を捨てている箇所が production code に 12 箇所 (test 除く):
internal/ddns/cloudflare.go L55 (json.Marshal), L58/L85/L115 (http.NewRequest)
internal/ddns/mydns.go L88 (io.ReadAll on response body)
internal/mode/check.go L63 (ipFetch)
internal/mode/keepalive.go L32 (ipFetch)
internal/mode/update.go L44 (ipFetch), L77/L96/L129/L148 (ReadDomainCache)
このうち分類が分かれる:
- 意図的に許容される無視 —
cached, _ := st.ReadDomainCache(...) は「キャッシュミスは無視して再取得」が正しい挙動
- 固定構造で実害が薄い —
json.Marshal(payload) (固定 struct), http.NewRequest(MethodPatch, url, body) (定数 URL)
- 隠蔽が起き得る —
mydns.go L88 の response body read、ipFetch の error 無視は本来のエラーをマスクする可能性
提案
全箇所を survey して以下のいずれかに置換:
- 1 のパターン: コメント追記で意図を明示 (
// cache miss intentional 等) または独自ヘルパーでラップ
- 2 のパターン:
must ヘルパーで初期化時 panic、または明示的 err check
- 3 のパターン: 本来の error handling に修正 (logging / 上位返却 / state 記録)
関連ファイル
internal/ddns/cloudflare.go
internal/ddns/mydns.go
internal/mode/check.go, keepalive.go, update.go
internal/ip/fetch.go (ipFetch の signature 確認)
優先度
低 — 実害が直ちに出る箇所はない、Go idiom との整合性向上目的。3 のパターンのみ中優先度。
観察
_ :=で error を捨てている箇所が production code に 12 箇所 (test 除く):internal/ddns/cloudflare.goL55 (json.Marshal), L58/L85/L115 (http.NewRequest)internal/ddns/mydns.goL88 (io.ReadAll on response body)internal/mode/check.goL63 (ipFetch)internal/mode/keepalive.goL32 (ipFetch)internal/mode/update.goL44 (ipFetch), L77/L96/L129/L148 (ReadDomainCache)このうち分類が分かれる:
cached, _ := st.ReadDomainCache(...)は「キャッシュミスは無視して再取得」が正しい挙動json.Marshal(payload)(固定 struct),http.NewRequest(MethodPatch, url, body)(定数 URL)mydns.goL88 の response body read、ipFetchの error 無視は本来のエラーをマスクする可能性提案
全箇所を survey して以下のいずれかに置換:
// cache miss intentional等) または独自ヘルパーでラップmustヘルパーで初期化時 panic、または明示的 err check関連ファイル
internal/ddns/cloudflare.gointernal/ddns/mydns.gointernal/mode/check.go,keepalive.go,update.gointernal/ip/fetch.go(ipFetch の signature 確認)優先度
低 — 実害が直ちに出る箇所はない、Go idiom との整合性向上目的。3 のパターンのみ中優先度。