Go: 提案：仕様：組み込みの結果タイプ（Rust、OCamlなど）を追加

Go 1.x言語は凍結されているため、言語変更の提案は現在、提案のレビュープロセスでは検討されていません（ご指摘のとおり、これはGo2です）。 すぐにこれに関する決定を期待しないことをあなたに知らせてください。

final_value := doThing(a).
    Then(func(resp) { doAnotherThing(b, resp.foo()) }).
    Then(func(resp) { FinishUp(c, resp.bar()) })!

これはGoにとって正しい方向ではないと思います。 ()) })! 、真剣に？ Goの主な目標は、学習のしやすさ、読みやすさ、使いやすさです。 これは役に立ちません。

誰かがredditスレッドで言ったよう合計タイプとジェネリックを間違いなく好むでしょう。

おそらく私は投稿で不明確でした：私は確かに結果タイプが合計タイプとジェネリックから構成されることを望みます。

私は、両方を追加しても（個人的には非常にありそうもないと思いますが）この機能を追加する際の妨げにならないように、これを指定しようとしていました。この機能はそれらに切り替えることができます（従来の一般的な構文でどのように見えるかの例を示し、Go sumタイプの問題にもリンクしています）。

結果の種類と目標の関係がわかりません。 エラー伝播とコンビネータに関するあなたのアイデアは、複数の結果パラメータの現在のサポートと同様に機能するように見えます。

@ianlancetaylorは、現在の結果タプルで一般的に機能するコンビネータを定義する方法の例を示しますか？ 可能であればそれを見たいと思いますが、そうではないと思います（この投稿によると）

@tarcieriその投稿は大きく異なり、 errorはResult<A>推奨される使用法には表示されません。 この問題は、投稿とは異なり、 result<int, error>示唆しているようです。これは、提案されたコンビネータがerror特別に認識していることを意味します。 誤解してしまったらお詫びします。

目的は、 resultをerrorに結合することではなく、RustのResultタイプまたはEitherと同様に、 Result resultが2つの値を運ぶことです。 HaskellのEither 。 どちらの言語でも、慣例により、2番目の値は通常errorタイプです（ただし、そうである必要はありません）。

この問題は、投稿とは異なり、結果を示唆しているようです

投稿は次のことを示唆しています。

type Result<A> struct {
    // fields
}

func (r Result<A>) Value() A {…}
func (r Result<A>) Error() error {…}

...それどころか、その投稿はerror前後に特化していますが、この提案は2番目の値にユーザー指定のタイプを受け入れます。

確かに、 result.Err()やresult.MapErr()ようなものは、この値が常にerrorです。

@tarcieri構造体の何が問題になっていますか？ https://play.golang.org/p/mTqtaMbgIF

@griesemerは、Goの投稿での

@tarcieriわかりました。 しかし、それ（非一般性、またはおそらく合計タイプがない）がここで問題である場合は、代わりにそれらの問題に対処する必要があります。 結果タイプのみを処理することは、特別なケースを追加することだけです。

Goにジェネリックスがあるかどうかは、ファーストクラスの結果タイプが役立つかどうかと直交します。 実装を自分で実装するものに近づけることができますが、提案でカバーされているように、コンパイラがファーストクラスの方法でそれについて推論できるようにすることで、たとえば、消費されていない結果について警告することができます。 単一の結果タイプを持つことも、提案のコンビネータを構成可能にするものです。

@tarcieri構成は、単一の結果構造体タイプでも可能です。

埋め込みまたは定義された構造体型を使用しない理由がわかりません。 エラーをチェックするための特殊なメソッドと構文があるのはなぜですか？ Goには、これらすべてを実行する手段がすでにあります。 これは、Go言語を定義せず、Rustを定義する機能を追加しているだけのようです。 そのような変更を実装するのは間違いです。

埋め込みまたは定義された構造体型を使用しない理由がわかりません。 エラーをチェックするための特殊なメソッドと構文があるのはなぜですか？

もう一度繰り返します。ジェネリックの結果タイプを使用するには...ジェネリックが必要です。 Goにはジェネリックはありません。 Goがジェネリックスを取得することを除いて、言語からの特別な場合のサポートが必要です。

おそらくあなたはこのようなことを提案していますか？

type Result struct {
    value interface{}
    err error
}

はい、これは「機能」します...型安全性を犠牲にして。 ここで、結果を消費するには、型アサーションを実行して、 interface{}型の値が期待どおりであることを確認する必要があります。 そうでない場合は、実行時エラーになります（現在のコンパイル時エラーとは対照的です）。

これは、Goが現在持っているものに対する大きな回帰になります。

この機能が実際に役立つためには、タイプセーフである必要があります。 Goの型システムは、特殊なケースの言語サポートなしで型安全な方法で実装するのに十分な表現力がありません。 少なくともジェネリックが必要であり、理想的にはタイプも合計する必要があります。

これは、Go言語を定義しない機能を追加しているだけのようです[...]。 そのような変更を実装するのは間違いです。

私は元の提案で同じくらいカバーしました：

「このアプローチには少し学習曲線が伴うことを認めます。そのため、コンビネータのイディオムに慣れていない人にとっては、プログラムの明確さに悪影響を与える可能性があります。個人的には、エラー処理のためのコンビネータが大好きですが、文化的にどのように理解できるかは間違いありません。 Goには不向きかもしれません。」

私は自分の疑惑を確認したように感じます。また、このような機能はGo開発者には簡単に理解できず、言語の単純さを重視する性質に反しているように感じます。 これはプログラミングパラダイムを活用しており、明らかに、Go開発者は理解も望んでもいないようであり、そのような場合は機能が間違っているように見えます。

彼らは錆を定義します

結果タイプはRust固有の機能ではありません。 それらは多くの関数型言語で見られます（例えば、HaskellのEitherとOCamlのresult ）。 そうは言っても、それらをGoに導入することは、あまりにも遠い橋のように感じます。

アイデアを共有していただきありがとうございますが、上記の例は納得がいかないと思います。 私にとって、AはBよりも優れています：

A
`` `resp、err：= doThing（a）
err！= nil {の場合
nilを返し、エラー
}
respの場合、err = doAnotherThing（b、resp.foo（））; err！= nil {
エラーを返す
}
respの場合、err = FinishUp（c、resp.bar（））; err！= nil {
エラーを返す
}

結果：= doThing（a）。
Then（func（resp）{doAnotherThing（b、resp.foo（））}）。
Then（func（resp）{FinishUp（c、resp.bar（））}）

result.isError（）{の場合
result.Error（）を返します
}
`` `

• Aはより読みやすく、大声で精神的にも読みやすくなっています。
• Aは行のフォーマット/折り返しを必要としません
• Aでは、エラー条件が明示的に実行を終了します。 精神的な否定は必要ありません。 Bは似ていません。
• Bでは、キーワード「Then」は条件付き因果関係を示していません。 キーワード「if」はそうです、そしてそれはすでにその言語にあります。
• Bでは、ラムダにパックすることによって、実行の最も可能性の高いブランチを遅くしたくありません

Aの方が読みやすいとは思いません。 実際、アクションはまったく目立ちません。 代わりに、一目見ただけで、多数のエラーが取得されて返されていることがわかります。

クロージャー本体が新しい行に配置されるようにBをフォーマットする場合、それが最も読みやすいフォーマットになります。

また、最後のポイントは少しばかげているようです。 関数呼び出しのパフォーマンスが非常に重要な場合は、必ず、より従来の構文を使用してください。

A @asから、通常のフローはインデントされるべきではないと思います。

if err != nil {
    return err
}

resp, err = doAnotherThing(b, resp.foo());
if  err != nil {
    return err
}

resp, err = FinishUp(c, resp.bar());
if  err != nil {
    return err
}

このスレッドからの興味深い観察の1つ：コピーと貼り付けを続ける元の例にはいくつかのエラーが含まれていました（最初のifはエラー時にnil, errを返し、次の2つはerrのみを返します

この特定のクラスのエラーは、Goコンパイラーによって検出されるようなものですが、構文の定型文が非常に多いと、コピーして貼り付けるときにそのようなエラーを簡単に見過ごせるようになることに注意してください。

これは提案をより良くするものではありません。 複数の値を返さないのは、明示的なエラー処理の結果であると想定されています。 関数内で同じエラーが発生した可能性もありますが、不要なカプセル化のためにそれらは表示されませんでした。

私は同意しません、それがこの種の提案の長所だと思います。 プログラムが行っているのがエラーを返し、それを処理しないことだけである場合、それは認知的オーバーヘッドとコードを浪費し、物事を読みにくくします。 このような機能を追加するということは、（それを使用することを選択するプロジェクトでは）エラーを処理するコードが実際に理解する価値のあることをしていることを意味します。

同意しないことに同意する必要があります。 提案の魔法のトークンは書くのは簡単ですが、理解するのは難しいです。 短くしたからといって、単純にしたわけではありません。

読みにくくすることは主観的なことなので、ここに私の意見があります。 この提案で私が目にするのは、魔法の関数と記号（非常に見逃しやすい）を備えた、より複雑でわかりにくいコードだけです。 そして、ケースAの場合、非常に単純で理解しやすいコードを非表示にするだけです。私にとっては、値を追加したり、重要な場所でコードを短縮したり、物事を単純化したりすることはありません。 言語レベルでそれらを扱うことに価値はありません。

提案が解決する唯一の問題は、はっきりとわかりますが、エラー処理の定型文です。 それが唯一の理由であるなら、それは私にとってそれだけの価値はありません。 構文ボイラープレートに関する議論は、実際には提案に反対しています。 その点では、はるかに複雑です。見逃しがちなすべての魔法の記号と角かっこです。 例Aには定型文がありますが、論理エラーは発生しません。 その文脈では、その提案から得られるものは何もありません。繰り返しになりますが、それはあまり有用ではありません。

Rustの機能はRustに任せましょう。

明確にするために、私はショートカットとして!接尾辞を追加することに夢中ではありませんが、単純化する単純な構文を考え出すというアイデアは好きです。

err = foo()
if err != nil {
  return err
}

その構文が特別な記号ではなくキーワードであっても。 これは言語についての私の最大の不満であり（個人的にはジェネリックスよりもさらに大きい）、コード全体にそのパターンが散らばっていると、読みにくく、騒々しいと思います。

また、コードで読みやすくなるので、 @ tarcieriがもたらすような連鎖を可能にする何かを見たいと思います。 @crekerがほのめかしている複雑さは、コードの信号対雑音比の向上によってバランスが取れていると思います。

私は、この提案がその定められた目標をどのように達成するかを完全には理解していません。

1. エラー処理の定型文を減らす：提案にはいくつかの架空のGoコードがあります：

   result := doThing(a).
   Then(func(resp) { doAnotherThing(b, resp.foo()) }).
   Then(func(resp) { FinishUp(c, resp.bar()) })
   
   if result.isError() {
   return result.Error()
   }
   

   関数リテラルの動作方法をさらに大幅に変更しない限り、 func(resp) { expr }がどのように動作するのかよくわかりません。 結果のコードは、次のようになります。

   result := doThing(a).
   Then(func(resp T) result(T, error) { return doAnotherThing(b, resp.foo()) }).
   Then(func(resp T) result(T, error) { return FinishUp(c, resp.bar()) })
   
   if result.isError() {
   return result.Error()
   }
   

   現実的なGoコードでは、中間式がこれより長く、独自の行に配置する必要があることもよくあります。 これは、今日の実際のGoコードで自然に発生

   result := doThing(a).
   Then(func(resp T) result(T, error) {
       return doAnotherThing(b, resp.foo())
   }).
   Then(func(resp T) result(T, error) {
       return FinishUp(c, resp.bar())
   })
   
   if result.isError() {
   return result.Error()
   }
   

   いずれにせよ、これは私に大丈夫だと思いますが、提案のその上の実際のGoコードのように、素晴らしいとは言えません。 その「Then」コンビネータは本質的に「return」の反対です。 （モナドに精通している場合、これは驚くことではありません。）これにより、「if」ステートメントを記述する必要がなくなりますが、関数を記述する必要が生じます。 全体として、それは実質的に良くも悪くもありません。 これは、新しいスペルの同じ定型ロジックです。

2. コンパイラーが結果について推論できるようにします。この機能が望ましい場合（ここではそれについて意見を表明していません）、この提案がどのように実質的に実現可能になるかわかりません。 彼らは私を直交していると思います。

3. エラー処理コンビネータ：この目標は提案によって確かに達成されますが、現在のGo言語のコンテキストでは、それを達成するために必要な変更のコストに見合う価値があるかどうかは完全には明らかではありません。 （これがこれまでの議論の主な論点だと思います。）

最もよく書かれたGoでは、この種のエラー処理ボイラープレートはコードのごく一部を構成します。 うまく書かれていると私が考えるいくつかのGoコードベースを簡単に見てみると、これは1桁の行のパーセンテージでした。 はい、それが適切な場合もありますが、多くの場合、再設計が必要であるという兆候です。 特に、コンテキストを追加せずにエラーを返すだけで、現在よりも頻繁に発生します。 それは「反イディオム」と呼ばれるかもしれません。 言語設計、図書館、ツール、純粋に社会的、またはそれらの組み合わせのいずれかで、Goがこの反イディオムを思いとどまらせるために何をすべきか、またはできるかについて議論する必要があります。 。 この提案が採択されるかどうかについても同様に議論したいと思います。 実際、この提案の目的であると私が信じているように、その反イディオムを表現しやすくすることは、間違ったインセンティブを設定する可能性があります。

現在、この提案は主に好みの問題として扱われています。 私の意見でそれをより説得力のあるものにするのは、その採用がバグの総数を減らすことを示す証拠でしょう。 良い最初のステップは、 Goコーパスの代表的なチャンクを変換して、ある種のバグが新しいスタイルで表現できないか、表現される可能性が低いことを示すことです。実際のGoコードの1行あたりx個のバグは次のように修正されます。新しいスタイル。 （新しいスタイルが他の種類のバグの可能性を高めることによって改善を相殺しないことを示すのははるかに難しいようです。そこでは、Goの前の古き良き時代のように、読みやすさと複雑さについての抽象的な議論をしなければならないかもしれません。コーパスが目立つようになりました。）

そのような裏付けとなる証拠が手元にあれば、より強力な主張をすることができます。

コンテキストを追加せずにエラーを返すだけで、現在よりも頻繁に発生します。 それは「反イディオム」と呼ばれるかもしれません。

この感情を反映させたいと思います。 この

if err := foo(x); err != nil {
    return err
}

単純化するべきではなく、落胆させるべきです。

if err := foo(x); err != nil {
    return errors.Wrapf(err, "fooing %s", x)
}

@peterbourgon

これに関する私の最大の問題は、エラーが盲目的に返されることではありません。 アクションは次のとおりです。 foo(x) ; はそれほど目に見えません。imhoは、アクション自体が新しい行への単純な戻りである代替の「機能的な」ソリューションよりも全体をかなり読みにくくします。

割り当てとアクションがifステートメント自体から分離されている場合でも、結果のステートメントは、アクションではなく結果にアクセントを付けます。 特に結果が重要な部分である場合、これは完全に有効です。 ただし、各ステートメントが（結果、エラー）タプルを取得し、エラー/リターンをチェックしてから、新しいタプルを取得しながら別のアクションを実行するステートメントが多数ある場合、結果自体は明らかにメインキャラクターではありません。プロット。

@urandom結果は（val、error）のペアだと思うので、エラー/リターンのチェックもプロットの主な文字だと思います。

すべてのif err != nil { return err }を避けるために、予約語（ reterrようなもの） if err != nil { return err }どうですか？

したがって、この

resp, err := doThing(a)
if err != nil {
    return nil, err
}
resp, err = doAnotherThing(b, resp.foo())
if err != nil {
    return nil, err
}
resp, err = FinishUp(c, resp.bar())
if err != nil {
    return nil, err
}

になります：

resp, _ := reterr doThing(a)
resp, _ = reterr doAnotherThing(b, resp.foo())
resp, _ = reterr FinishUp(c, resp.bar())

reterrは基本的に、呼び出された関数の戻り値をチェックし、それらのいずれかがエラーでnilでない場合は戻ります（エラー以外の戻り値ではnilを返します）。

＃18721としてますます聞こえる

@tarcieri reflectパッケージの一部を使用してください。 私はあなたの提案のようなものをシミュレートすることができます。
しかし、私はそれをする価値はないと思います。

https://play.golang.org/p/CC5txvAc0e

func main() {

    result := Do(func() (int, error) {
        return doThing(1000)
    }).Then(func(resp int) (int, error) {
        return doAnotherThing(200000, resp)
    }).Then(func(resp int) (int, error) {
        return finishUp(1000000, resp)
    })

    if result.err != nil {
        log.Fatal(result.err)
    }

    val := result.val.(int)
    fmt.Println(val)
}

@iporsut反射には2つの問題があり、表面上は問題を「解決」しているように見えるかもしれませんが、この特定の問題に対する不適切な解決策になります。

1. 型安全性なし：リフレクションでは、クロージャーが適切に型指定されているかどうかをコンパイル時に判断できません。 代わりに、プログラムはタイプに関係なくコンパイルされ、それらが一致しない場合はランタイムクラッシュが発生します。
2. 巨大なパフォーマンスオーバーヘッド：あなたが提案しているアプローチは、 go-linqによって提供されるアプローチからそれほど遠くありません。 彼らは、この目的のために反射を使用することは「5倍-10倍遅い」と主張しています。 ここで、すべての単一の呼び出しサイトでこの量のオーバーヘッドを想像してください。

私にとって、これらの問題のいずれかは、Goがすでに持っているものから大きく後退しており、同時に、完全に非スターターです。

私はGoとそれがエラーを処理する方法が好きです。 ただし、もっと簡単かもしれません。 Goでのエラー処理に関する私の考えのいくつかを次に示します。

現在の方法：

resp, err := doThing(a)
if err != nil {
    return nil, err
}

resp, err = doAnotherThing(b, resp.foo())
if err != nil {
    return nil, err
}

resp, err = FinishUp(c, resp.bar())
if err != nil {
    return nil, err
}

A：

resp, _ := doThing(a) 
resp, _ = doAnotherThing(b, resp.foo())
resp, _ = FinishUp(c, resp.bar())
// return if error is omited, otherwise deal with it as usual (if err != nil { return err })
//However, this breaks semantics of Go and may mislead due to the usa of _ (__ or !_ could be used to avoid such misleading)

B：

resp, err := doThing(a)?
resp, err = doAnotherThing(b, resp.foo())?
resp, err = FinishUp(c, resp.bar())?
// ? indicates that it will return in case of error (more explicit)
// or any other indication could be used
// this approach is preferred for its explicitness

C：

resp, err := doThing(a)
return if err

resp, err = doAnotherThing(b, resp.foo())
return if err

resp, err = FinishUp(c, resp.bar())
return if err
// if err return err
// or if err return (similar to javascript return)
// this one is my favorite, almost no changes to the language, very readable and less SLOC

D：

resp, _ := return doThing(a)
resp, _ = return doAnotherThing(b, resp.foo())
resp, _ = return FinishUp(c, resp.bar())
// or 
resp = throw FinishUp(c, resp.bar())
// this one is also very readable (although maybe a litle less than option **C**) and even less SLOC than **C**
// at this point I'm not sure whether C or D is my favorite )) 

//This applies to all approaches above
// if the function that contains any of these options has no value to return, exit the function. E.g.:
func test() {
    resp, _ := return doThing(a) // or any of other approaches
    // exit function
}

func test() ([]byte, error) {
    resp, _ := return doThing(a) // or any of other approaches
    // return whatever is returned by doThing(a) (this function of course must return ([]byte, error))
}

英語を失礼します。そのような変更が可能かどうか、またパフォーマンスのオーバーヘッドが発生するかどうかはわかりません。

これらのアプローチのいずれかが気に入った場合は、次のルールに従って気に入ってください。

A =👍
B =😄
C =❤️
D =🎉

そして👎あなたがアイデア全体を嫌うなら））

このようにして、いくつかの統計を取得し、「+ 1」のような不要なコメントを回避できます。

私の「提案」について詳しく説明します...

// no need to explicitely define error in return statement, much like throw, try {} catch in java
func test() int {
     resp := throw doThing() // "returns" error if doThing returns (throws) an error
     return resp // yep, resp is int
}

func main() {
     resp, err := test() // the last variable is always error type
     if err != nil {
          os.Exit(0)
     }
}

繰り返しますが、そのようなことが可能かどうかはわかりません））

もう1つのクレイジーなオプションは、 errorという単語をもう少し魔法のようにすることです。 代入（または短い宣言）の左側で使用できるようになり、魔法の関数のように機能します。

res, error() := doThing()
// Shorthand for
res, err := doThing()
if err != nil {
  return 0, ..., 0, err
}

具体的には、 error()は次のとおりです。

1. 割り当ての目的では、タイプerrorように扱われます。
2. nilが割り当てられている場合、何も起こりません。
3. nil値が割り当てられている場合、囲んでいる関数はすぐに戻ります。 error型である必要があり、 error()割り当てられた値が割り当てられている最後の値を除いて、すべての戻り値は0に設定されます。

エラーに何らかの変更を適用する場合は、次の操作を実行できます。

res, error(func (e error) error { return fmt.Errorf("foo: %s", error)})
  := doThing()

この場合、関数が戻る前に割り当てられた値にクロージャが適用されます。

これは少し醜いですが、これは主に、クロージャに対処しなければならないという構文上の肥大化によるものです。 標準ライブラリはこれをうまく修正できます。たとえば、 error(errors.Wrapper("foo"))を使用すると、正しいラッパークロージャが生成されます。

別の方法として、nullary error()構文が見落とされる可能性が高い場合は、代わりにerror(return)をお勧めします。 キーワードを使用すると、誤解のリスクが軽減されます。 ただし、クロージャーケースにはうまく拡張できません。

Goを書いた人は誰でも、コードの主要な目的から注意をそらすエラー処理ボイラープレートの不幸な急増に遭遇しました。 そのため、2015年にRobPikeがこの問題に取り組みました。 MartinKühlが指摘しているように、エラー処理を簡素化するためのRobの提案は次のとおりです。

エラーを処理したいすべてのインターフェースに職人技の1回限りのモナドを実装する必要がありますが、それでも冗長で反復的だと思います

そのため、今日でもこのトピックに多くの関与があります。

理想的には、次のような解決策を見つけることができます。

1. 繰り返し発生するエラー処理の定型文を減らし、コードパスの主な目的に焦点を合わせます。
2. エラーを伝播するときのエラーのラップを含む、適切なエラー処理を奨励します。
3. 明快さとシンプルさというGoの設計原則を順守します。
4. 可能な限り広い範囲のエラー処理状況に適用できます。

次のように機能する新しいキーワードcatch:の導入を提案します。

現在のフォームの代わりに：

res, err := doThing()
if err != nil {
  return 0, ..., 0, err
}

私たちは書くでしょう：

res, err := doThing() catch: 0, ..., 0, err

これは、上記の現在のフォームコードとまったく同じように動作します。 具体的には、 catch:の左側にある関数と割り当てが最初に実行されます。 次に、戻り引数の1つがerror型であり、その値がnil以外の場合にのみ、 catch:はreturnステートメントとして機能します。権利。 doThing()から返されたerrorタイプが0個または複数ある場合、 catch:を使用すると構文エラーになります。 doThing()から返されるエラー値がnil場合、 catch:からステートメントの終わりまでのすべてが無視され、評価されません。

Nemanja Mijailovicの最近のブログ投稿「 Goでの

func parse(r io.Reader) (*point, error) {
  var p point

  if err := binary.Read(r, binary.BigEndian, &p.Longitude); err != nil {
    return nil, err
  }

  if err := binary.Read(r, binary.BigEndian, &p.Latitude); err != nil {
    return nil, err
  }

  if err := binary.Read(r, binary.BigEndian, &p.Distance); err != nil {
    return nil, err
  }

  if err := binary.Read(r, binary.BigEndian, &p.ElevationGain); err != nil {
    return nil, err
  }

  if err := binary.Read(r, binary.BigEndian, &p.ElevationLoss); err != nil {
    return nil, err
  }

  return &p, nil
}

これは代わりになります：

func parse(input io.Reader) (*point, error) {
  var p point

  err := read(&p.Longitude) catch: nil, errors.Wrap(err, "Failed to read longitude")
  err = read(&p.Latitude) catch: nil, errors.Wrap(err, "Failed to read Latitude")
  err = read(&p.Distance) catch: nil, errors.Wrap(err, "Failed to read Distance")
  err = read(&p.ElevationGain) catch: nil, errors.Wrap(err, "Failed to read ElevationGain")
  err = read(&p.ElevationLoss) catch: nil, errors.Wrap(err, "Failed to read ElevationLoss")

  return &p, nil
}

利点：

1. エラー処理のための最小限の追加ボイラープレートに近い。
2. ステートメントの左側にあるエラー処理の手荷物を最小限に抑え、右側にローカライズされたエラー処理を使用して、コードの主な目的へのフォーカスを改善します。
3. さまざまな状況で機能し、複数の戻り値の場合にプログラマーに柔軟性を提供します（たとえば、エラーに加えて成功したアイテムの数のインジケーターを返したい場合）。
4. 構文は単純で、新旧両方のGoユーザーが簡単に理解して採用できます。
5. エラーコードをより簡潔にすることにより、適切なエラー処理を促進することに部分的に成功しています。 エラーコードがコピーアンドペーストされる可能性がわずかに低くなり、それによって一般的なコピーアンドペーストエラーの発生が減少する可能性があります。

短所：

1. このアプローチは、エラーを伝播する前にラッピングエラーを促進することは何もないため、適切なエラー処理を促進することに完全には成功しません。 私の理想的な世界では、この新しい構文では、 catch:によって返されるエラーは、新しいエラーまたはラップされたエラーのいずれかである必要がありますが、 catch:左側の関数によって返されるエラーと同じではありません。
2. これはすべて構文上の糖衣であり、言語では必要ないと主張する人もいるかもしれません。 反論は、Goでの現在のエラー処理は構文上のトランス脂肪であり、この提案はそれを排除するだけであるというものかもしれません。 広く採用されるためには、プログラミング言語は使いやすいものでなければなりません。 大部分はGoが成功しますが、エラー処理の定型文は特に大量の例外です。
3. 呼び出した関数からエラーを「キャッチ」しているのでしょうか、それとも呼び出した人にエラーを「スロー」しているのでしょうか。 明示的なスローなしでcatch:を使用するのは適切ですか？ 予約語は必ずしもcatch:ある必要はありません。 他の人はより良いアイデアを持っているかもしれません。 予約語の代わりに演算子にすることもできます。

Goを書いた人は誰でも、コードの主要な目的から注意をそらすエラー処理ボイラープレートの不幸な急増に遭遇しました。

それは真実ではありません。 私はGoでプログラムをかなり行っていますが、ボイラープレートのエラー処理に問題はありません。 エラー処理コードを書くことは、私がほとんど気付かないほどプロジェクトを開発するのに非常にわずかな時間を消費します、そしてそれは言語への変更を正当化しない私見です。

Goを書いた人は誰でも、コードの主要な目的から注意をそらすエラー処理ボイラープレートの不幸な急増に遭遇しました。

それは真実ではありません。 私はGoでプログラムをかなり行っていますが、ボイラープレートのエラー処理に問題はありません。 エラー処理コードを書くことは、私がほとんど気付かないほどプロジェクトを開発するのに非常にわずかな時間を消費します、そしてそれは言語への変更を正当化しない私見です。

エラー処理コードの記述にかかる時間については何も言いませんでした。 私はそれがコードの中心的な目的から気をそらすと言っただけです。 たぶん私は「Goを読んだ人は皆、不幸なことにエラー処理の急増に遭遇した...」と言ったはずです。

だから、 @ cznic 、あなたにとっての質問は、ボイラープレートの処理に過度のエラーがあると感じたGoコードを読んだことがあるのか​​、それとも理解しようとしているコードの邪魔になったのかということだと思います。

誰も私の提案が好きではありません😅
とにかく、いくつかの構文があり、最良のもの（いくつかの投票システム）に投票し、ここまたはreadmeにリンクを含める必要があります

たぶん私は「Goを読んだ人は皆、不幸なことにエラー処理の急増に遭遇した...」と言ったはずです。

それは真実ではない。 私は、現在の最先端のエラー処理の明示性と適切な局所性を好みます。 この提案は、私が今まで見た他のどの提案と同様に、コードIMHOを読みにくくし、維持するのを悪化させます。

だから、 @ cznic 、あなたにとっての質問は、ボイラープレートの処理に過度のエラーがあると感じたGoコードを読んだことがあるのか​​、それとも理解しようとしているコードの邪魔になったのかということだと思います。

いいえ。私の経験では、Goは非常に読みやすいプログラミング言語です。 もちろん、そのクレジットの半分はgofmtに送られます。

私自身の経験では、依存するステートメントがたくさんあると、実際にドラッグが始まります。各ステートメントはエラーをスローする可能性があり、エラー処理は合計されてすぐに古くなります。 5行のコードは20になります。

@cznic
私の経験では、ボイラープレートの処理でエラーが発生すると、コードが読みにくくなります。 エラー処理自体はほとんど同じであるため（発生する可能性のあるエラーラッピングはありません）、一種のフェンス効果が発生します。コードの一部をすばやくスキャンすると、ほとんどの場合、大量のエラー処理が表示されます。 したがって、最大の問題である、プログラムの最も重要な部分である実際のコードは、この目の錯覚の背後に隠されており、コードの一部が何であるかを実際に確認することは非常に困難です。

エラー処理は、コードの主要部分であってはなりません。 残念ながら、それはまさにそれで終わることがよくあります。
他の言語でのステートメント構成が非常に人気があるのには理由があります。

エラー処理自体はほとんど同じであるため（エラーはありません）
発生する可能性のあるラッピング）、それは一種のフェンス効果を生成します。
コードの一部をすばやくスキャンすると、ほとんどの場合、大量のコードが表示されます。
エラー処理の。

これは非常に主観的な立場です。 それは、ifステートメントが
コードを判読不能にするか、K＆Rスタイルの中括弧で判読不能にします。

私の見解では、goのエラー処理の明示性はすぐに薄れていきます
パターンが壊れていることに気付くまで、親しみやすさの背景に。
人間の目が非常に得意なこと。 欠落しているエラー処理、
エラー変数は_などに割り当てられます。

入力するのは負担です。間違いはありません。 しかし、Goは最適化されていません
コード作成者、それはリーダーのために明示的に最適化します。

2017年5月16日火曜日午後5時45分、Viktor Kojouharov < [email protected]

書きました：

@cznic https://github.com/cznic
私の経験では、ボイラープレートの処理でエラーが発生すると、コードが作成されます
はるかに読みにくい。 エラー処理自体はほとんど同じであるため
（発生する可能性のあるエラーラッピングはありません）、一種のフェンスを生成します
効果、コードの一部をすばやくスキャンすると、ほとんどの場合終了します
大量のエラー処理が表示されます。 したがって、最大の問題は、実際の
プログラムの最も重要な部分であるコードは、このオプティカルの背後に隠されています
幻想、実際に何の部分を見るのが非常に難しい
コードは約です。

エラー処理は、コードの主要部分であってはなりません。 残念ながら、かなり
多くの場合、それはまさにそれであることになります。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/19991#issuecomment-301702623 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAAcA4ydpBFiapYBOBUyUjg6du5Dnjs5ks5r6VQjgaJpZM4M-dud
。

コードの一部をすばやくスキャンすると、ほとんどの場合、大量のコードが表示されます。
エラー処理の。

これは非常に主観的な立場です。

非常に主観的でありながら広く共有されています。

ロブ自身が言ったように、

Goプログラマー、特にこの言語に不慣れなプログラマーの間でよくある議論のポイントは、エラーの処理方法です。 会話は、シーケンスの回数でしばしば嘆きに変わります

if err != nil {
    return err
}

現れます。

公平を期すために、Robは、Goエラー処理に関するこの認識は「不幸で、誤解を招きやすく、簡単に修正できる」と続けました。 しかし、彼はその記事のほとんどを、知覚を修正するための彼の推奨する方法を説明する説明しているように、ロブの処方自体には問題があります。 マーティンの批判に加えて、ロブの提案は、 @ cznicがGoエラー処理で

たぶん問題は、私たちが置き換える能力を持っていたかどうかです

res, err := doThing()
if err != nil {
  return nil, err
}

次のようなもので：

res, err := doThing() catch: nil, err

それを使用しますか、それとも4行バージョンを使い続けますか？ あなたの個人的な好みに関係なく、このような代替案はGoコミュニティで広く採用され、慣用的になると思いますか？ 短いバージョンが読みやすさに悪影響を与えるという議論の主観性を考えると、プログラマーとの私の経験では、彼らは単一行バージョンに強く引き寄せられるだろうと言っています。

実際の話：go 1は固定されており、特にこの基本的な方法では変更されません。

Go 2がいくつかのテンプレートタイプを実装するまで、ある種のオプションタイプを提案することは無意味です。 その時点で、すべてが変わります。

2017年5月16日には、午後11時46分で、ビリーHinners [email protected]書きました：

コードの一部をすばやくスキャンすると、ほとんどの場合、大量のコードが表示されます。
エラー処理の。

これは非常に主観的な立場です。

非常に主観的でありながら広く共有されています。

ロブ自身が言ったように、

Goプログラマー、特にこの言語に不慣れなプログラマーの間でよくある議論のポイントは、エラーの処理方法です。 会話は、シーケンスの回数でしばしば嘆きに変わります

err！= nil {の場合
エラーを返す
}
現れます。

公平を期すために、Robは、Goエラー処理に関するこの認識は「不幸で、誤解を招きやすく、簡単に修正できる」と続けました。 しかし、彼はその記事のほとんどを、知覚を修正するための彼の推奨する方法を説明することに費やしています。 残念ながら、マーティン・クールがよく説明しているように、ロブの処方自体には問題があります。 マーティンの批判に加えて、ロブの提案は、 @ cznicがGoエラー処理で

たぶん問題は、私たちが置き換える能力を持っていたかどうかです

res、err：= doThing（）
err！= nil {の場合
nilを返し、エラー
}
次のようなもので：

res、err：= doThing（）catch：nil、err

それを使用しますか、それとも4行バージョンを使い続けますか？ あなたの個人的な好みに関係なく、このような代替案はGoコミュニティで広く採用され、慣用的になると思いますか？ 短いバージョンが読みやすさに悪影響を与えるという議論の主観性を考えると、プログラマーとの私の経験では、彼らは単一行バージョンに強く引き寄せられるだろうと言っています。

—
コメントしたのでこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

Go 2がいくつかのテンプレートタイプを実装するまで、ある種のオプションタイプを提案することは無意味です。 その時点で、すべてが変わります。

このスレッドのタイトルが示すように、Go 2について話していると思いました。また、「Go 2」は、「決して」の婉曲表現ではないと完全に信じています。 実際、Go 1が修正されていることを考えると、Goの議論の大部分をGo2に費やす必要があります。

そうは言っても、Goの冗長性について不満を言う人は誰でも
エラー処理には、エラーの目的という基本的なポイントが欠けています
Goでの処理は、エラーではないケースを簡潔で目立たないものにするために_not_です
できるだけ。 むしろ、Goのエラー処理戦略の目標は、強制することです
常に、次の場合に何が起こるかを考慮するコードの作成者
機能が失敗し、そして最も重要なのは、クリーンアップ、元に戻す、および回復する方法
発信者に戻る前に。

エラー処理ボイラープレートを隠すためのすべての戦略は、私には
これを無視します。

2017年5月16日火曜日、23：51 Dave

本当の話：go 1は修正されており、特にこれでは変更されません
基本的な方法。

Go 2が実装するまで、ある種のオプションタイプを提案するのは無意味です
テンプレートタイプの一部。 その時点で、すべてが変わります。

2017年5月16日には、午後11時46分で、ビリーHinners [email protected]書きました：

コードの一部をすばやくスキャンすると、ほとんどの場合、
質量
エラー処理の。

これは非常に主観的な立場です。

非常に主観的でありながら広く共有されています。

ロブ自身が言ったように、

Goプログラマー、特に初心者のプログラマーの間での共通の論点
言語は、エラーを処理する方法です。 会話はしばしば
シーケンスの回数で嘆く

err！= nil {の場合
エラーを返す
}

現れます。

公平を期すために、Robは、Goエラー処理に関するこの認識は次のように述べています。
「残念ながら、誤解を招きやすく、簡単に修正できます。」 しかし、彼はそのほとんどを費やしています
彼を説明する記事https://blog.golang.org/errors-are-values
知覚を修正するための推奨される方法。 残念ながら、ロブの
説明されているように、処方自体は問題があります
https://www.innoq.com/en/blog/golang-errors-monads/マーティンによってとてもよく
キュール。 マーティンの批評に加えて、ロブの提案はまた、
@cznichttps ：//github.com/cznicがGoで評価していると言っている地域
エラー処理。

たぶん問題は、私たちが置き換える能力を持っていたかどうかです

res、err：= doThing（）
err！= nil {の場合
nilを返し、エラー
}

次のようなもので：

res、err：= doThing（）catch：nil、err

それを使用しますか、それとも4行バージョンを使い続けますか？
あなたの個人的な好みに関係なく、あなたは次のような代替案を考えますか
これはGoコミュニティで広く採用され、慣用的になりますか？
短いバージョンが逆にという議論の主観性を考えると
読みやすさに影響します、プログラマーとの私の経験は彼らがそうするだろうと言います
単線バージョンに強く引き寄せられます。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/19991#issuecomment-301787215 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAAcAwATgoJwL5WV-0nffLjLB9L86GYOks5r6ai3gaJpZM4M-dud
。

むしろ、Goのエラー処理戦略の目標は、強制することです
常に、次の場合に何が起こるかを考慮するコードの作成者
機能が失敗し、そして最も重要なのは、クリーンアップ、元に戻す、および回復する方法
発信者に戻る前に。

さて、Goはその目標を達成しませんでした。 デフォルトでは、Goを使用すると、返されたエラーを無視できます。多くの場合、どこかで正常に機能しなくなるまで、そのことを知ることさえできません。 それどころか、Goコミュニティの例外（これは要点を証明するための単なる例です）で大いに嫌われているので、アプリケーションがクラッシュするため、それらを考慮する必要があります。 それはしばしば私たちにすべてを捕まえて無視するという問題につながりますが、それはプログラマーのせいです。

基本的に、Goでのエラー処理はオプトインです。 すべてのエラーを処理する必要があるというのは、口頭の慣習に関するものです。 それが実際にあなたにエラーを処理することを強制するならば、目標は達成されるでしょう。 たとえば、コンパイル時のエラーや警告があります。

それを念頭に置いて、ボイラープレートを隠しても誰も傷つけません。 口頭での慣習は今でも維持され、プログラマーは今のようにエラー処理をオプトインします。

Goのエラー処理戦略の目標は、強制することです
常に、次の場合に何が起こるかを考慮するコードの作成者
機能が失敗し、そして最も重要なのは、クリーンアップ、元に戻す、および回復する方法
発信者に戻る前に。

それは間違いなく高貴な目標です。 ただし、プライマリフローの可読性とコードの意図とのバランスをとる必要があるのが目標です。

Goプログラマーとして、私はあなたに言うことができます。
読みやすさを損なうためのGoのエラー処理。 何も見えない
他の人が書いたコードを読むことに不快感を感じないので、トレードオフする
プログラマーに行きなさい。

0:10時水曜、2017年5月17日には、ビリーHinners [email protected]
書きました：

Goのエラー処理戦略の目標は、強制することです
常に、次の場合に何が起こるかを考慮するコードの作成者
機能が失敗し、そして最も重要なのは、クリーンアップ、元に戻す、および回復する方法
発信者に戻る前に。

それは間違いなく高貴な目標です。 それは目標ですが、それは
プライマリフローの可読性とコードの意図に対してバランスが取れています。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/19991#issuecomment-301794653 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAAcAzfcu5hq86xxVj85qfOquVawHh44ks5r6a5zgaJpZM4M-dud
。

@davecheney 、エラー処理は明示的であり、後で延期されるべきではないことに同意しますが（もちろん、_で実行できます）、1つの関数でエラーを処理するためにエラーを「バブリング」する戦略もあります。追加情報を追加または削除します（クライアントに送信する前に）。 私の個人的な問題は、同じ4行のコードを何度も書かなければならないことです。

例えば：

getNewToken（id int64）（トークン、エラー）{

user := &User{ID:id}

u, err := user.Get();
if err != nil {
    return Token{}, err
}

token, err := token.New(u);
if err != nil {
    return Token{}, err
}
return token, nil

}
私はここでエラーを処理していません、私はそれを返すだけです。 この種のコードを読むときは、エラーの「処理」をスキップする必要があり、コードの主な目的を見つけるのが困難です。

上記のコードは、次のようなものに簡単に置き換えることができます。

getNewToken（id int64）（トークン、エラー）{

user := &User{ID:id}

u, err := throw user.Get(); //throw should also wrap the error

token, err := throw token.New(u);

return token, nil

}
そのようなコードは、より読みやすく、不要性の少ない（IMHO）コードです。 また、エラーは、この関数が使用されている関数で処理される可能性があり、処理する必要があります。

Goプログラマーとして、私はGoのエラー処理の冗長性が読みやすさを損なうことはないとあなたに言うことができます。

同意します。

無関係なメモについて：

また、「結果」タイプは提案に対して少し具体的すぎるように思われます。 たぶん、型は実際には2つのバリアントの列挙型です。 列挙型の概念がある場合は、結果またはオプションパッケージをツリーから作成し、それを言語に追加する前に実験して、実際には再利用できず、優れているだけの余分な構文やメソッドをたくさん追加する必要はありません。結果タイプの場合。 列挙型がGoで役立つかどうかはわかりませんが、より一般的なケースについて議論できれば、より具体的な結果タイプの場合もおそらくより強力になります（おそらく私は間違っています）。

func getNewToken（id int64）（トークン、エラー）{
user：=＆User {ID：id}

u, err := user.Get()
if err != nil {
    return Token{}, err
}

return token.New(u)

}

同等のようです。

0:34時水曜、2017年5月17日には、Kiura [email protected]は書きました：

@davecheney https://github.com/davecheney 、私はあなたに同意しますが
そのエラー処理は明示的であり、後で延期されるべきではありません（
もちろん、あなたは_）で行うことができます、「バブリング」する戦略もあります
1つの機能でそれらを処理するためのエラー、追加情報を追加するためのエラー、または
削除します（クライアントに送信する前に）。 私の個人的な問題は私が持っていることです
同じ4行のコードを何度も書く

例えば：

getNewToken（id int64）（トークン、エラー）{

user：=＆User {ID：id}

u、err：= user.Get（）;
err！= nil {の場合
トークン{}を返す、エラー
}

トークン、エラー：= token.New（u）;
err！= nil {の場合
トークン{}を返す、エラー
}
トークンを返す、nil

}
私はここでエラーを処理していません、私はそれを返すだけです。 そして私が読んだとき
この種のコードでは、エラーの「処理」をスキップする必要があり、見つけるのが困難です
コードの主な目的

上記のコードは、次のようなものに簡単に置き換えることができます。

getNewToken（id int64）（トークン、エラー）{

user：=＆User {ID：id}

u、err：= throw user.Get（）; // throwもエラーをラップする必要があります

トークン、エラー：= throw token.New（u）;

トークンを返す、nil

}
そのようなコードは、より読みやすく、不要性の少ない（IMHO）コードです。 そしてその
エラーは、この関数が存在する関数で処理される可能性があり、処理する必要があります
使用済み。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/19991#issuecomment-301802010 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAAcA9sIRXX7RSdDcUOidpe-qLTR7unNks5r6bP3gaJpZM4M-dud
。

また、「結果」タイプは提案に対して少し具体的すぎるように思われます。 たぶん、型は実際には2つのバリアントの列挙型です。 列挙型の概念がある場合は、結果またはオプションパッケージをツリーから作成し、それを言語に追加する前に実験して、実際には再利用できず、優れているだけの余分な構文やメソッドをたくさん追加する必要はありません。結果タイプの場合。 列挙型がGoで役立つかどうかはわかりませんが、より一般的なケースについて議論できれば、より具体的な結果タイプの場合もおそらくより強力になります（おそらく私は間違っています）。

元の提案で述べられているように、結果タイプは理想的には合計タイプとして実装され（たとえば、列挙型ala Rustの）、言語にそれらを追加するためのオープンな提案があります。

ただし、追加の言語サポートなしで再利用可能な結果タイプライブラリを実装するには、合計タイプだけでは不十分です。 また、ジェネリックが必要です。

この提案は、ジェネリックスに依存せず、代わりにコンパイラーからの特殊なケースのヘルプに依存する結果タイプを実装するというアイデアを模索していました。

これを投稿したので、これを追求するための最良の方法は、言語レベルのジェネリックスのサポートを使用することであることに同意します。

@davecheney 、確かに、この場合はほとんど違いはありませんが、エラーを返す関数で3〜4回の呼び出しがある場合はどうなりますか？

PS私はエラーを処理するGo1構造に反対していません、私はそれがより良いかもしれないと思います。

元の提案で述べられているように、結果タイプは理想的には合計タイプとして実装され（たとえば、列挙型ala Rustの）、言語にそれらを追加するためのオープンな提案があります。

申し訳ありませんが、私はもっと明確にすべきでした：私はこの声明を主張していました：

Goの結果タイプも必要ではなく、特殊なケースのコンパイラーの魔法を利用するだけでよいと思います。

私には悪い考えのように感じます。

ただし、追加の言語サポートなしで再利用可能な結果タイプライブラリを実装するには、合計タイプだけでは不十分です。 また、ジェネリックが必要です。

この提案は、ジェネリックスに依存せず、代わりにコンパイラーからの特殊なケースのヘルプに依存する結果タイプを実装するというアイデアを模索していました。

これを投稿したので、これを追求するための最良の方法は、言語レベルのジェネリックスのサポートを使用することであることに同意します。

はい、十分に公平です。 私はあなたの最後の声明に同意します。 とにかくGo2を待たなければならない場合は、最初にもっと一般的な問題を解決したほうがよいでしょう（実際に問題であると仮定して）:)

また、Rob Pikeは、上記のようにエラー処理に関する記事を書きました。 このアプローチは問題を「修正」しているように見えますが、別の問題が発生します。それは、インターフェースによるコードの膨張です。

「明示的なエラー処理」と「詳細なエラー処理」を混同しないことが重要だと思います。 Goは、ユーザーにエラー処理を委任するのではなく、すべてのステップでエラー処理を検討するように強制したいと考えています。 エラーをスローする可能性のある呼び出す関数ごとに、エラーを処理するかどうか、およびその方法を決定する必要があります。 エラーを無視することを意味する場合もあれば、再試行することを意味する場合もあります。多くの場合、エラーを呼び出し元に渡して処理することを意味します。

Robの記事は素晴らしく、Effective Go 2の一部である必要がありますが、これはこれまでのところしか理解できない戦略です。 特に異種の呼び出し先を処理する場合、管理するエラー処理がたくさんあります

エラー処理に役立つシンタックスシュガーやその他の機能を検討するのは不合理ではないと思います。 Goエラー処理の基本を損なわないことが重要だと思います。 たとえば、発生するすべてのエラーを処理する関数レベルのエラーハンドラーを確立するのは悪いことです。 これは、例外処理が通常行うことをプログラマーが実行できるようにすることを意味します。つまり、エラーの考慮をステートメントレベルの問題からブロックレベルまたは関数レベルの問題に移します。 それは間違いなく哲学に反しています。

@billyh 「Goでのエラー処理パターン」の記事に関しては、他の解決策があります。

• https://play.golang.org/p/q6O1FbwHzi
• https://play.golang.org/p/nRW2Un9y_O

@egonelbre
これらのソリューションは、同じタイプの操作を繰り返し実行している場合にのみ適しています。 通常はそうではありません。 したがって、これを実際に適用することはほとんどできません。

@urandomでは、現実的な例を示してください。

確かに私はもっと複雑な例を取ることができます：

func (conversion *PageConversion) Convert() (page *kb.Page, errs []error, fatal error)

これらはどこにでも当てはまるわけではないことは理解していますが、改善したい例の適切なリストがなければ、まともな議論をする方法はありません。

@egonelbre

https://github.com/juju/juju/blob/01b24551ecdf20921cf620b844ef6c2948fcc9f8/cloudconfig/providerinit/providerinit.go

免責事項：私はjujuを使用したことも、コードを読んだこともありません。 それは私が頭のてっぺんに知っている単なる「生産」製品です。 このようなタイプのエラー処理（独立した操作の間にエラーがチェックインされる）がgoの世界で普及していることは合理的に確信しており、これに遭遇していない人はいないと思います。

@urandom同意します。 実際のコードなしで議論する際の主な問題は、人々が実際の問題ではなく、問題の「要点」を覚えていることです。これは、問題の記述を過度に単純化することにつながることがよくあります。 _PS： goで1つのました。_

たとえば、これらの実際の例から、考慮する必要のある他のいくつかのことがわかります。

• 良いエラーメッセージ
• エラー値に基づく回復/代替パス
• フォールバック
• エラーのあるベストエフォート実行
• ハッピーケースロギング
• 失敗ログ
• 障害トレース
• 複数のエラーが返されます
• _もちろん、これらのいくつかは一緒に使用されます_
• ...おそらく私が逃したもの...

「幸せ」と「失敗」の道だけではありません。 私はこれらが解決できないと言っているのではなく、ただそれらを計画して議論する必要があるということです。

@egonelbreは、今週のGolang Weeklyの別の例で、MarioZupanによる「Goで静的ブログジェネレーターを作成する」というタイトルの記事にあります。

func (ds *GitDataSource) Fetch(from, to string) ([]string, error) {
    fmt.Printf("Fetching data from %s into %s...\n", from, to)
    if err := createFolderIfNotExist(to); err != nil {
        return nil, err
    }
    if err := clearFolder(to); err != nil {
        return nil, err
    }
    if err := cloneRepo(to, from); err != nil {
        return nil, err
    }
    dirs, err := getContentFolders(to)
    if err != nil {
        return nil, err
    }
    fmt.Print("Fetching complete.\n")
    return dirs, nil
}

注：マリオのコードに対する批判を暗示しているわけではありません。 実際、私は彼の記事をとても楽しんだ。
残念ながら、このような例はすべてGoソースでは一般的すぎます。 Goコードは、関心のある1行のこの線路パターンに引き寄せられ、その後に3行の同一またはほぼ同一のボイラープレートが何度も繰り返されます。 マリオのように、可能な場合は割り当てと条件付きを組み合わせると、少し役立ちます。

コードの行を最小限に抑えることを主な目的としてプログラミング言語が設計されているかどうかはわかりませんが、a）意味のあるコードと定型文の比率は、プログラミング言語の品質の（多くの）有効な尺度の1つである可能性があります。b）プログラミングの多くはエラー処理を伴うため、このパターンはGoコードに浸透し、したがって、過剰なボイラープレートのこの特定のケースを合理化するメリットがあります。

良い代替案を特定できれば、それは急速に採用され、Goの読み取り、書き込み、保守がさらに楽しくなると思います。

Rebecca Skinner（@cercerilla）は、Goのエラー処理の欠点に関する優れた記事と、スライドデッキのMonadic Error Handling inGoのソリューションとしてモナドを使用した分析を共有しました。 私は最後に彼女の結論が特に好きでした。

彼の記事でレベッカのデッキを参照するための@davecheneyのおかげでシンプル債務Reduxのそれを見つけるために私を可能にしました。 （Go 2に対する私のバラ色の楽観主義をより厳しい現実に基づいて行ってくれたDaveにも感謝します。）

Goコードは、関心のある1行のこの線路パターンに引き寄せられ、その後に3行の同一またはほぼ同一のボイラープレートが何度も繰り返されます。

すべての制御フロー制御ステートメントは重要です。 エラー処理ラインは、正確性の観点から非常に重要です。

ボイラープレートに対する意味のあるコードの比率は、プログラミング言語の品質の（多くの）有効な尺度の1つである可能性があります

エラー処理ステートメントが意味をなさないと誰かが考えた場合は、コーディングを頑張ってください。結果に近づかないようにしたいと思います。

@davecheneyのSimplicityDebt Reduxでカバーされているポイントの1つに対処するには（これについてはカバーしましたが、繰り返す必要があると思います）。

次の質問は、このモナディック形式がエラーを処理する単一の方法になるかどうかです。

このようなものがエラーを処理する「単一の」方法になるためには、標準ライブラリ全体とすべての「Go2」互換プロジェクトで行われる重大な変更である必要があります。 それは賢明ではないと思います。Python2/ 3の大失敗は、そのような分裂が言語エコシステムにどのように損害を与える可能性があるかを示しています。

この提案で述べたように、結果タイプが自動的に同等のタプルフォームに強制変換できる場合は、既存のコードとの下位互換性を維持しながら、このアプローチを全面的に採用する架空のGo2標準ライブラリの観点からケーキを持って食べることができます。 これにより、興味のある人はそれを利用できますが、それでもGo1で作業したいライブラリは、そのまま使用できます。 ライブラリの作成者は、古いスタイルを使用してGo1とGo2の両方で動作するライブラリを作成するか、Monadicスタイルを使用してGo2のみで動作するライブラリを作成するかを選択できます。

エラー処理の「古い方法」と「新しい方法」は、言語のユーザーがそれについて考える必要がなく、必要に応じて「古い方法」で作業を続けることができるという点で互換性があります。 これには特定の概念的な純粋さが欠けていますが、既存のコードを変更せずに動作させ続け、最新だけでなくすべてのバージョンの言語で動作するライブラリを開発できるようにするよりもはるかに重要ではないと思います。

エラーインターフェイスモデルと新しいモナディック型の両方を引き続きサポートすることは、紛らわしいようであり、Go2.0の初心者に不明確なガイダンスを提供します。

それらはブレーキです。言語をそのまま凍結するか、言語を進化させて、偶発的な複雑さを追加し、以前のやり方をレガシーいぼに委ねます。 古い機能が廃止されたが互換性があるか、または重大な変更の形で戸外にあるかにかかわらず、古い機能を置き換える新しい機能を追加することは、この言語のユーザーが考えるものであるため、これらは本当に2つのオプションだけだと思います関係なく学ぶ必要があります。

言語を変えることはできないと思いますが、たとえGo2がこれを完全に採用したとしても、新参者に「古い方法」と「新しい方法」の両方を学ぶことを避けてもらいます。 あなたはまだGo1とGo2の分裂を残されているでしょう、そして新参者は違いが何であるか疑問に思うでしょう、そしてとにかく「Go1」を学ばなければならないことになるでしょう。

下位互換性は、言語とコードの互換性を教えるのに役立つと思います。構文が古くなっていても、Goを教える既存の資料はすべて引き続き有効です。 Goの教材をすべて調べて、古い構文を無効にする必要はありません。教材は、暇なときに、新しい構文があるという通知を追加することができます。

「それを行うには複数の方法がある」というのは、一般的に単純性とミニマリズムというGoの哲学に反することを理解していますが、新しい言語機能を追加するために支払わなければならない代償です。 新しい言語機能は、その性質上、古いアプローチを廃止します。

私は確かに、Gopherにとってより自然な方法で同じコア問題を解決する方法があるかもしれないことを認めたいと思いますが、既存のアプローチからのそのような不快な変更ではありません。

考慮すべきもう1つのこと：Goは言語を習得しやすくするという模範的な仕事をしてきましたが、それだけが人々を言語に参加させることに伴う障害ではありません。 Goのエラー処理の冗長性を見て、それによって延期されている人がたくさんいると言っても過言ではありません。その中には、言語の採用を拒否する人もいます。

言語の改善が現在それによって延期されている人々を引き付けることができるかどうか、そしてこれが言語を学びにくくすることとどのようにバランスをとるかを尋ねる価値があると思います。

ただし、モナディックエラー処理のようなことを行うと、エラーについて考えさせるというGoの哲学に反します。 モナディックエラー処理とJavaスタイルの例外処理は、セマンティクスが非常に似ています（ただし、構文は異なります）。 Goは、考えたときにエラー処理コードを追加するだけでなく、プログラマーが各エラーを明示的に処理することを期待するという、意図的に異なる哲学を採用しました。 実際、 return nil, errイディオムは厳密に言えば最適ではありません。これは、おそらく追加の有用なコンテキストを追加できるためです。

Goのエラー処理に対処する試みは、これを念頭に置いておく必要があり、エラーについて考えるのを簡単に避けられないようにする必要があると思います。

@alercah私はあなたが今言ったすべてのものとは違うことを懇願する必要があります...

モナディックエラー処理のようなことをすることは、エラーについて考えさせるというGoの哲学に反します。

Rustから来ているので、Rust（またはRustコンパイラ）は実際にはGoよりもエラーについて考えさせられると思います。 RustのResultタイプには＃[must_use]属性があります。これは、未使用の結果がコンパイラ警告を生成することを意味します。 これはGoではそうではありません（Rebecca Skinnerは彼女の講演でこれに取り組んでいます）：Goコンパイラは、たとえば未処理のerror値について警告しません。

Rust型システムは、コードで対処されるすべてのエラーケースを強制します。そうでない場合、それは型エラー、またはせいぜい警告です。

モナディックエラー処理とJavaスタイルの例外処理は、セマンティクスが非常に似ています（ただし、構文は異なります）。

これが真実ではない理由を分析しましょう。

エラー伝播戦略

• Go：戻り値、明示的に伝播
• Java：非ローカルジャンプ、暗黙的に伝播
• Rust：戻り値、明示的に伝播

エラーの種類

• Go：関数ごとに1つの戻り値、通常は(success, error)タプル
• Java：メソッドからスローされる可能性のあるすべての例外の集合和を表す、多くの例外タイプで構成されるチェック済み例外。 また、宣言されておらず、いつでもどこでも発生する可能性のある未チェックの例外。
• Rust：関数ごとに1つの戻り値、通常はResult合計タイプ（例： Result<Success, Error>

全体として、エラー処理に関しては、GoはJavaよりもRustにはるかに近いと感じています。GoとRustのエラーは単なる値であり、例外ではありません。 伝播を明示的にオプトインする必要があります。 異なるタイプのエラーを、たとえばラッピングによって、特定の関数が返すエラーに変換する必要があります。 これらは両方とも、異なるタイプのシステム機能（タプルと一般的な合計タイプ）を使用するだけで、最終的に成功値とエラーのペアを表します。

Rustが、クレートごとに選択的に使用して暗黙的なエラー処理を行うことができるいくつかの抽象化を提供するいくつかの例外があります（つまり、明示的なエラー変換では、手動でエラーを伝播する必要があります）。 たとえば、 Fromトレイトを使用して、エラーをあるタイプから別のタイプに自動的に変換できます。 個人的には、エラーをある明示的なタイプから別の明示的なタイプに自動的に変換できる特定のパッケージに完全にスコープされたポリシーを定義できることは、欠点ではなく利点だと思います。 Rustの特性システムでは、自分のクレート内のタイプに対してFromのみを定義できるため、距離を置いた不気味なアクションを防ぐことができます。

ただし、これはこの提案の範囲外であり、Goが連携して機能しないいくつかの言語機能が含まれているため、Goがこれらのタイプの暗黙的な変換をサポートする「リスク」があるような滑りやすい坂道はないと思います。 、少なくともGoがジェネリックスと特性/型クラスを追加するまでは。

この問題について私の2セントを投げる。 この種の機能は、単一のアプリケーションが多数の補助データソースと通信し、簡単な方法で結果を作成する企業（私自身の雇用主など）にとって非常に役立つと思います。

これが私たちが持っているであろういくつかのコードフローの代表的なデータサンプルです

func generateUser(userID : string) (User, error) {
      siteProperties, err := clients.GetSiteProperties()
      if err != nil {
           return nil, err
     }
     chatProperties, err := clients.GetChatProperties()
      if err != nil {
           return nil, err
     }

     followersProperties, err := clients.GetFollowersProperties()
      if err != nil {
           return nil, err
     }


// ... (repeat X5)
     return createUser(siteProperties, ChatProperties, followersProperties, ... /*other properties here */), nil
}

Goは、ユーザーに各ポイントでエラーについて考えさせるように設計されているという多くのプッシュバックを理解していますが、関数の大部分がT, err返すコードベースでは、これは実質的な実際のコードの膨張につながります誰かが追加の関数呼び出しを行った後にエラー処理コードを追加するのを忘れ、エラーが黙ってチェックされないため、実際には本番環境の失敗につながりました。 さらに、実際、私たちの最もおしゃべりなサービスのいくつかが最大20％以上のエラー処理であるのは珍しいことではなく、興味深いものはほとんどありません。

さらに、このエラー処理ロジックの大部分は同一であり、逆説的に、コードベースでの明示的なエラー処理の量が多いため、干し草の山に少し針があるため、例外的なケースが実際に興味深いコードを見つけるのは困難です。 '演劇の現象。

特にこの提案が解決策ではない理由は確かにわかりますが、この定型文を削減するための「何らかの」方法が必要であると私は信じています。

もう少し怠惰な考え：

Rustの末尾の?は、優れた構文です。 ただし、Goの場合、エラーコンテキストの重要性を考えると、次のバリエーションを提案する可能性があります。

• 末尾の? 、Go用に変更されたRustのように機能します。 具体的には、最後の戻り値がタイプerror関数でのみ使用でき、最後の戻り値もタイプerror関数呼び出しの直後に表示される必要があります（注： errorも実装するすべての型を許可しますが、 errorを要求すると、nilインターフェイスの問題が発生するのを防ぐことができます。これは素晴らしいボーナスです）。 その結果、エラー値がnil以外の場合、 ?が表示される関数が関数から返され、最後のパラメーターがエラー値に設定されます。 名前付きの戻り値を使用する関数の場合、他の値に対してゼロを返すか、現在格納されている値を返すことができます。 そうでない関数の場合、他の戻り値は常にゼロです。
• 末尾の.?("opening %s", file)は上記のように機能しますが、エラーを変更せずに返すのではなく、エラーを構成する関数を介して渡される点が異なります。 大まかに言えば、 .?(str, vals...)はfmt.Errorf(str + ": %s", vals..., err)ように侵食を変化させます
• おそらく、パッケージが識別されたエラータイプをエクスポートする場合をカバーする、 .?構文のバリアントまたは別のバージョンのいずれかが存在する必要があります。

＃19412（合計タイプ）および＃21161（エラー処理）および＃15292（ジェネリック）に関連します。

関連している：

新しいエラー処理機能の「ドラフトデザイン」：
https://go.googlesource.com/proposal/+/master/design/go2draft.md

エラー設計に関するフィードバック：
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback

個別のリターンタイプを作成する代わりに、 @ LegoRemixが話しているgo-langのこの1つの厄介な機能を解決するための、 @ alercahの提案が好き

ゼロ値を推測しないようにRustのRFCにさらに従い、 catch式を導入して、本体がエラーを返した場合に返されるものを明示的に指定できるようにすることをお勧めします。

したがって、この：

func generateUser(userID string) (*User, error) {
    siteProperties, err := clients.GetSiteProperties()
    if err != nil {
         return nil, errors.Wrapf(err, "error generating user: %s", userID)
    }

    chatProperties, err := clients.GetChatProperties()
    if err != nil {
         return nil, errors.Wrapf(err, "error generating user: %s", userID)
    }

    followersProperties, err := clients.GetFollowersProperties()
    if err != nil {
         return nil, errors.Wrapf(err, "error generating user: %s", userID)
    }

    return createUser(siteProperties, ChatProperties, followersProperties), nil
}

このDRYコードになります：

func generateUser(userID string) (*User, error) {
    siteProperties := clients.GetSiteProperties()?
    chatProperties := clients.GetChatProperties()?
    followersProperties := clients.GetFollowersProperties()?

    return createUser(siteProperties, ChatProperties, followersProperties), nil
} catch (err error) {
    return nil, errors.Wrapf(err, "error generating user: %s", userID)
}

そして、使用している機能することを要求?オペレータも定義する必要がありますcatch

@bradfitz @peterbourgon @SamWhited多分これには別の問題があるはずですか？

@sheerun ?演算子とcatch handleステートメントは、新しいエラー処理ドラフトデザインのcheck演算子とhandleステートメントと非常によく似ています（https： //go.googlesource.com/proposal/+/master/design/go2draft.md）。

好奇心旺盛な人にとっては、これがcheckとhandleコードのようになります。

func generateUser(userID string) (*User, error) {
    handle err { return nil, errors.Wrapf(err, "error generating user: %s", userID) }

    siteProperties := check clients.GetSiteProperties()
    chatProperties := check clients.GetChatProperties()
    followersProperties := check clients.GetFollowersProperties()

    return createUser(siteProperties, chatProperties, followersProperties), nil
}

私が変更する唯一のことは、暗黙のhandleを取り除き、チェックが使用されている場合はそれを定義する必要があることです。 これにより、開発者がチェックを怠惰に使用したり、エラーの処理方法やラップ方法を考えたりするのを防ぐことができます。 暗黙のリターンは別個の機能である必要があり、以前に提案されたように使用できます。

func generateUser(userID string) (*User, error) {
    handle err { return _, errors.Wrapf(err, "error generating user: %s", userID) }

    siteProperties := check clients.GetSiteProperties()
    chatProperties := check clients.GetChatProperties()
    followersProperties := check clients.GetFollowersProperties()

    return createUser(siteProperties, chatProperties, followersProperties), nil
}

この提案の作成者として、この提案は＃15292によって事実上無効にされ、 https： //go.googlesource.com/proposal/+/master/design/go2draft-contracts.mdのように機能することに注意してresult()の特殊なケースで型ポリモーフィズムを可能にする新しい構文を提案します。たとえば、コントラクトを使用してそれを回避できる場合、この提案はもはや意味がないと思います。

そのうちの少なくとも1つがGo2で終了する可能性が高いように思われるので、この特定の提案を閉じる必要があるかどうか、そして人々がhandle代わりに結果タイプにまだ興味を持っているかどうか疑問に思います、例えば契約が利用可能であると仮定して書き直されること。

（私はおそらくその仕事をする時間がないことに注意してください、しかし他の誰かがこのアイデアを前向きに見ることに興味があるなら、それを行ってください）

@sheerun Go 2エラー処理に関するフィードバックとアイデアを
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback

および/またはこの包括的なリスト_Go2エラー処理で考慮すべき要件：_
https://gist.github.com/networkimprov/961c9caa2631ad3b95413f7d44a2c98a