Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Behavior of HasType and HasInterface is counter-intuitive

オープン
#145 コメント 1 件 リアクション 1 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
go
領域
backend

調査の方向性

markers/markers.go から始め、特に If とその UnwrapOnce の使用を確認してから、multi-errors に対する HasType と HasInterface のトラバーサル動作を Is および As と比較します。Sourcegraph PR 62992 における property-based testing のコンテキストを確認します。トラバーサルの違いを解決または文書化し、選択した動作に対するカバレッジを追加すれば完了です。

索引モデルが issue の本文から書いたものです。

説明

Both of these functions call If which does a traversal of the causal chain, it does not traverse the full tree. Specifically, If internally calls UnwrapOnce and doesn't handle the multi-error case, whereas functions like Is and As separately handle the multi-error case.

This leads to counter-intuitive behavior; you can have a value x of type T, and errors.Is(err, x) may be true, but errors.HasType(err, T{}) may fail.

I noticed this behavior while trying to add property-based tests to better understand the behavior of HasType here. https://github.com/sourcegraph/sourcegraph/pull/62992

It would be valuable to either:

  • Change the implementation of If to traverse the full tree
  • OR Add a separate function which does a tree traversal (not just the "causal chain") and use that from HasType and HasInterface
  • OR Add a cautionary warning to HasType and HasInterface's docs which describe the behavior in the presence of multi-errors.
主要言語
Go
スター
2.5k
フォーク
75
30日以内にマージされた PR はありません

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

cockroachdb/errors のほかの issue

cockroachdb/errors の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。