私はこれが前進するための最良の方法であることに同意します：シンプルなデザインで最も一般的な問題を修正します。

私はバイクシェッドをしたくありません（この会話を延期してください）が、Rustはそこに行き、読みやすさを向上させるために、組み込み関数ではなく?接尾辞演算子で最終的に解決しました。

gopherconの提案は、検討されたアイデアの中で?を引用し、それが破棄された3つの理由を示しています。1つ目（「制御フローの転送は原則としてキーワードを伴う」）と3つ目（「ハンドラーはより自然に定義される」）キーワードを使用するので、チェックも適用する必要があります」）はもう適用されません。 2つ目は文体です。つまり、接尾辞演算子が連鎖に対してより適切に機能する場合でも、次のような場合にはさらに悪化する可能性があるということです。

check io.Copy(w, check newReader(foo))

それよりも：

io.Copy(w, newReader(foo)?)?

しかし、今は次のようになります。

try(io.Copy(w, try(newReader(foo))))

呼び出されている主な関数がもう明らかではないので、これは明らかに3つのうちの悪い方だと思います。

したがって、私のコメントの要点は、 ?を使用しないというgophercon提案で引用された3つの理由はすべて、このtry提案には当てはまらないということです。 ?は簡潔で非常に読みやすく、ステートメント構造（内部関数呼び出し階層を含む）を曖昧にすることはなく、連鎖可能です。 提案されたtry()がすでに行っている以上に制御フローを覆い隠さずに、ビューからさらに多くの混乱を取り除きます。

明確にするために：

しますか

func f() (n int, err error) {
  n = 7
  try(errors.New("x"))
  // ...
}

（0、 "x"）または（7、 "x"）を返しますか？ 後者だと思います。

（内部ヘルパー関数のように）装飾や処理がない場合、エラーリターンに名前を付ける必要がありますか？ 私はそうは思わないでしょう。

あなたの例は7, errors.New("x")返します。 これは、まもなく提出される完全なドキュメント（https://golang.org/cl/180557）で明確になっているはずです。

tryを使用するために、エラー結果パラメーターに名前を付ける必要はありません。 関数が据え置き関数または他の場所でそれを参照する必要がある場合にのみ、名前を付ける必要があります。

呼び出し元の制御フローに影響を与える組み込みの_function_に本当に不満があります。 Go 1で新しいキーワードを追加できないことを感謝しますが、魔法の組み込み関数でその問題を回避することは私には間違っているように思えます。 他のビルトインのシャドウイングは、制御フローの変更ほど予測できない結果にはなりません。

後置?の見た目は気に入らないが、それでもtry()を上回っていると思う。

編集：まあ、私はパニックが存在し、キーワードではないことを完全に忘れることができました。

詳細な提案は現在ここにあり（フォーマットの改善が間もなく行われる予定です）、多くの質問に答えることができれば幸いです。

@dominikh詳細な提案ではこれについて詳しく説明していますが、 panicとrecoverは、制御フローにも影響を与える2つの組み込み関数であることに注意してください。

改善のための1つの説明/提案：

if the last argument supplied to try, of type error, is not nil, the enclosing function’s error result variable (...) is set to that non-nil error value before the enclosing function returns

代わりにこれはis set to that non-nil error value and the enclosing function returnsと言うことができますか？ （s / before / and）

最初に読んだとき、 before the enclosing function returnsは、関数が返される直前の将来のある時点で、おそらく後の行で、エラー値を_最終的に_設定するように見えました。 正しい解釈は、tryによって現在の関数が返される可能性があるということです。 これは現在の言語にとって驚くべき動作であるため、より明確なテキストが歓迎されます。

これは単なる砂糖だと思います。少数の声の反対者がif err != nil ...の繰り返しの使用についてゴランをからかい、誰かがそれを真剣に受け止めました。 問題ないと思います。 不足しているのは、次の2つの組み込み機能だけです。

https://github.com/purpleidea/mgmt/blob/a235b760dc3047a0d66bb0b9d63c25bc746ed274/util/errwrap/errwrap.go#L26

なぜ誰かがこのような関数を書くのかわからないが、想定される出力は何になるのか

try(foobar())

foobarが(error, error) $を返した場合

制御フローに関する以前の懸念を撤回し、 ?の使用を提案しなくなりました。 ひざまずく対応をお詫びします（ただし、完全な提案が利用可能になった後、問題が提出されていれば、これは起こらなかったことを指摘したいと思います）。

単純化されたエラー処理の必要性には同意しませんが、それは敗戦だと確信しています。 提案に記載されているtryは、それを行うための最も悪い方法ではないようです。

@webermasterプロポーザルのドキュメントで説明されているように、最後のerrorの結果のみが、 tryに渡される式に特別です。

@dominikhのように、私も単純化されたエラー処理の必要性に同意しません。

垂直方向の複雑さを水平方向の複雑さに移行しますが、これはめったに良い考えではありません。

ただし、エラー処理の提案を単純化することを絶対に選択する必要がある場合は、これが私の好ましい提案になります。

このような変換をせずに簡単に実行できるエラーを返す関数のサブセットでtryを使用するようにGoコードを変換するツールを（受け入れられる段階で）これに伴うことができれば便利です。セマンティクスの変更。 私には3つの利点があります。

• この提案を評価するとき、人々はコードベースでtryがどのように使用されるかをすぐに理解することができます。
• tryがGoの将来のバージョンに登場した場合、人々はそれを利用するためにコードを変更したいと思うでしょう。 簡単なケースを自動化するツールがあると、非常に役立ちます。
• 大規模なコードベースをすばやく変換してtryを使用する方法があると、実装の効果を大規模に調べるのが簡単になります。 （たとえば、正確性、パフォーマンス、およびコードサイズ。）ただし、実装は、これを無視できるほど考慮に入れるほど単純な場合があります。

裸のtry(foo())が実際に呼び出し元の関数から解放されると、結果に応じて関数の流れが変わる可能性があるという視覚的な手がかりが失われると思います。

十分に慣れればtryで作業できると思いますが、コードレビューの暗黙のフローを効率的に認識するためにtryを強調するために追加のIDEサポート（またはそのようなもの）が必要になると思います/デバッグセッション

私が最も懸念しているのは、deferステートメントが満足できるように戻り値に名前を付ける必要があることです。

コミュニティが不満を言っている全体的なエラー処理の問題は、 if err != nilの定型文とエラーへのコンテキストの追加の組み合わせだと思います。 よくある質問では、後者は別の問題として意図的に省略されていると明確に述べられていますが、これは不完全な解決策になると思いますが、次の2つのことを考えた後、チャンスを与えたいと思います。

1. 関数の先頭でerrを宣言します。
   これは機能しますか？ 結果の延期と名前のない問題を思い出します。 そうでない場合、提案はこれを考慮する必要があります。

func sample() (string, error) {
  var err error
  defer fmt.HandleErrorf(&err, "whatever")
  s := try(f())
  return s, nil
}

1. 以前と同じように値を割り当てますが、 if err != nilボイラープレートを持つヘルパーwrapf関数を使用します。

func sample() (string, error) {
  s, err := f()
  try(wrapf(err, "whatever"))
  return s, nil
}
func wrapf(err error, format string, ...v interface{}) error {
  if err != nil {
    // err = wrapped error
  }
  return err
}

どちらかがうまくいけば、私はそれに対処することができます。

func sample() (string, error) {
  var err error
  defer fmt.HandleErrorf(&err, "whatever")
  s := try(f())
  return s, nil
}

これは機能しません。 deferは、戻り値とは関係のないローカルのerr変数を更新します。

func sample() (string, error) {
  s, err := f()
  try(wrapf(err, "whatever"))
  return s, nil
}
func wrapf(err error, format string, ...v interface{}) error {
  if err != nil {
    // err = wrapped error
  }
  return err
}

それはうまくいくはずです。 ただし、nilエラーの場合でもwrapfを呼び出します。
これも（継続して）機能し、IMOははるかに明確になります。

func sample() (string, error) {
  s, err := f()
  if err != nil {
      return "", wrap(err)
  }
  return s, nil
}

tryを使用させる人は誰もいません。

なぜ誰かがこのような関数を書くのかわからないが、想定される出力は何になるのか

try(foobar())

foobarが(error, error) $を返した場合

関数から複数のエラーを返すのはなぜですか？ 関数から複数のエラーを返す場合は、最初に関数を2つの別々のエラーに分割し、それぞれが1つのエラーのみを返すようにする必要があります。

例を挙げて詳しく教えてください。

@cespare ： tryを使用するように、 tryに適した既存のコードを書き換えるgo fixを誰かが書くことができるはずです。 既存のコードをどのように単純化できるかを理解しておくと役立つ場合があります。 tryは単なる構文上の糖衣であり、一般的なパターンを、本質的に同じ出力コードを生成する短いソースコードに置き換えるため、コードサイズやパフォーマンスに大きな変化はないと予想されます。 tryを使用するコードは、少なくともtryが導入されたバージョンであるGoバージョンを使用するようにバインドされることにも注意してください。

@lestrrat ： tryが制御フローを変更できることを学ぶ必要があることに同意しました。 IDEはそれを簡単に強調できると思います。

@Goodwine ： @ randall77がすでに指摘しているように、最初の提案は機能しません。 私たちが考えた1つのオプション（ただし、ドキュメントでは説明されていません）は、 errorの結果を示す事前に宣言された変数を持つ可能性です（最初に存在する場合）。 これにより、結果に名前を付ける必要がなくなり、 deferで使用できるようになります。 しかし、それはさらに魔法になります。 それは正当化されていないようです。 戻り結果に名前を付ける際の問題は本質的に表面的なものであり、それが最も重要なのは、 go docとその友人によって提供される自動生成されたAPIにあります。 これらのツールでこれに対処するのは簡単です（このテーマに関する詳細な設計ドキュメントのFAQも参照してください）。

@nictuku ：明確化のためのあなたの提案について（s / before / and /）：あなたが参照している段落の直前のコードは正確に何が起こるかを明確にしていると思いますが、私はあなたのポイントを理解しています、s / before / and / may散文をより明確にします。 変更します。

CL180637を参照してください。

私は実際にこの提案が本当に好きです。 しかし、私には1つの批判があります。 Goの関数の出口点は、常にreturnマークされています。 パニックも出口点ですが、これらは壊滅的なエラーであり、通常は発生す​​ることを意図していません。

returnではなく、ありふれたものである関数の出口点を作成すると、コードがはるかに読みにくくなる可能性があります。 講演でこれについて聞いたことがありますが、このコードがどのように構成されているかを理解するのは難しいです。

func CopyFile(src, dst string) error {
    r, err := os.Open(src)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    defer r.Close()

    w, err := os.Create(dst)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }

    if _, err := io.Copy(w, r); err != nil {
        w.Close()
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }

    if err := w.Close(); err != nil {
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
}

このコードは大きな混乱のように見えるかもしれず、エラー処理ドラフトでは「意味のある」ものでしたが、 tryを使用した同じものと比較してみましょう。

func CopyFile(src, dst string) error {
    defer func() {
        err = fmt.Errorf("copy %s %s: %v", src, dst, err)
    }()
    r, err := try(os.Open(src))
    defer r.Close()

    w, err := try(os.Create(dst))

    defer w.Close()
    defer os.Remove(dst)
    try(io.Copy(w, r))
    try(w.Close())

    return nil
}

繰り返されるコードがはるかに少ないので、これを一目見て、見栄えが良くなると思うかもしれません。 ただし、最初の例で関数が返したすべてのスポットを見つけるのは非常に簡単でした。 それらはすべてインデントされ、 returnで始まり、その後にスペースが続きます。 これは、すべての条件付き戻り値が条件付きブロック内にある必要があり、それによってgofmt標準によってインデントされるためです。 returnは、前述のように、壊滅的なエラーが発生したことを言わずに関数を終了する唯一の方法でもあります。 2番目の例では、 returnが1つしかないため、関数_ever_が返す必要があるのはnilだけのようです。 最後の2つのtry呼び出しは見やすいですが、最初の2つは少し難しく、どこかにネストされている場合、つまりproc := try(os.FindProcess(try(strconv.Atoi(os.Args[1]))))のようにするとさらに難しくなります。

関数から戻ることは「神聖な」ことであるように思われます。そのため、関数のすべての出口点はreturnでマークする必要があると私は個人的に考えています。

誰かがすでにこれを5年前に実装しました。 あなたが興味を持っているなら、あなたはすることができます
この機能を試す

https://news.ycombinator.com/item?id=20101417

5年前にASTプリプロセッサを使用してGoでtry（）を実装し、実際のプロジェクトで使用しました。これは非常に便利でした： https ：//github.com/lunixbochs/og

エラーチェックが多い関数で使用した例を次に示します。https ：//github.com/lunixbochs/poxd/blob/master/tls.go#L13

これに費やした努力に感謝します。 これは私がこれまでに見た中で最も厄介な解決策だと思います。 しかし、デバッグ時に多くの作業が発生すると思います。 デバッグするたびにunwrappingtryとifブロックを追加し、完了時に再ラップするのは面倒です。 また、考慮する必要のある魔法のerr変数についても気になります。 私は明示的なエラーチェックに悩まされたことがないので、おそらく私は間違った人に尋ねます。 それはいつも「デバッグの準備ができている」と私を驚かせました。

@griesemer
エラーラッピングを処理する方法としてのdeferの提案された使用に関する私の問題は、私が示したスニペット（以下で繰り返す）の動作があまり一般的ではないことです。そうでないとき。

のように..初心者はこれを知らないでしょう、これのために彼らがバグを持っているならば、彼らは「もちろん、私は名前付きのリターンが必要です」に行きません、彼らはそれがうまくいくはずで、それがうまくいかないのでストレスを感じるでしょう。

var err error
defer fmt.HandleErrorf(err);

tryはすでに魔法のようであるため、最後まで行って、その暗黙のエラー値を追加することもできます。 Goのすべてのニュアンスを知っている人ではなく、初心者のことを考えてください。 それが十分に明確でない場合、私はそれが正しい解決策ではないと思います。

または...このように延期を使用することを提案しないでください。より安全でありながら読みやすい別の方法を試してください。

@deanveloper確かに、この提案（さらに言えば、同じことを試みようとする提案）は、明示的に表示されるreturnステートメントをソースコードから削除します。これが、結局のところ、提案の要点です。そうですね。 すべて同じifステートメントとreturnsの定型文を削除します。 returnを保持する場合は、 tryを使用しないでください。

この種の制御フローがGo（および他の多くの言語）で表現される方法であるため、 returnステートメント（およびpanic ）をすぐに認識するために使用されます。 returnの場合と同じように、 tryも、慣れてから制御フローを変更するものとして認識されることは、それほど理解されていないようです。 優れたIDEサポートがこれにも役立つことは間違いありません。

私には2つの懸念があります：

• 名前付きの返品は非常に混乱を招き、これにより、新しく重要なユースケースが奨励されます。
• これにより、エラーにコンテキストを追加することをお勧めしません

私の経験では、各呼び出しサイトの直後にエラーにコンテキストを追加することは、簡単にデバッグできるコードを用意するために重要です。 そして、名前付きの返品は、ある時点で私が知っているほぼすべてのGo開発者に混乱を引き起こしました。

よりマイナーでスタイル上の懸念は、残念ながら、コードの何行がtry(actualThing())でラップされるかということです。 try()でラップされたコードベースのほとんどの行が表示されることを想像できます。 それは残念なことです。

これらの懸念は微調整で対処されると思います。

a, b, err := myFunc()
check(err, "calling myFunc on %v and %v", a, b)

check()はtry()とほとんど同じように動作しますが、関数の戻り値を一般的に渡す動作をドロップし、代わりにコンテキストを追加する機能を提供します。 それでもリターンがトリガーされます。

これにより、 try()の利点の多くが保持されます。

• ビルトインです
• 既存の制御フローWRTに従って延期します
• これは、エラーにコンテキストを追加するという既存の慣行とよく一致しています。
• errors.Wrap(err, "context message")などのエラーラッピングの現在の提案やライブラリと連携します
• その結果、クリーンなコールサイトになります。 a, b, err := myFunc()行に定型文はありません
• defer fmt.HandleError(&err, "msg")でエラーを説明することは引き続き可能ですが、推奨する必要はありません。
• checkのシグネチャは、ラップしている関数から任意の数の引数を返す必要がないため、少し単純です。

@ s4n-gtこのリンクをありがとう。 気づかなかった。

@Goodwineポイントを取得しました。 より直接的なエラー処理サポートを提供しない理由については、設計ドキュメントで詳しく説明されています。 また、（昨年のGopherconでドラフト設計が公開されてから）1年ほどの間に、明示的なエラー処理に対する満足のいく解決策が出てこなかったことも事実です。 これが、この提案が意図的にこれを省略している理由です（代わりに、 deferを使用することを提案しています）。 この提案は、その点で将来の改善への扉をまだ開いたままにしています。

この提案では、テストとベンチマークがエラーを返すことができるようにパッケージテストを変更することに言及しています。 「ささやかなライブラリの変更」ではありませんが、 func main() errorを受け入れることも検討できます。 それは小さなスクリプトを書くことをはるかに良くするでしょう。 セマンティクスは次と同等です。

func main() {
  if err := newmain(); err != nil {
    println(err.Error())
    os.Exit(1)
  }
}

最後の批判。 提案自体に対する批判ではなく、「流れを制御する機能」の反論に対する一般的な反応に対する批判です。

「関数がフローを制御しているのが気に入らない」に対する応答は、「 panicもプログラムのフローを制御している！」というものです。 ただし、 tryには適用されない、 panicがこれを実行しても問題がない理由はいくつかあります。

1. panicは、直感的に実行でき、スタックのラップを解除し続けるため、初心者のプログラマーにとっては使いやすいものです。 panicがどのように機能するかを理解するために、それがどのように機能するかを調べる必要はありません。 初心者のプログラマーはrecoverについて心配する必要さえありません。なぜなら、初心者は通常、パニック回復メカニズムを構築していないからです。

2. panicは見やすい名前です。 それは心配をもたらします、そしてそれはそうする必要があります。 コードベースにpanicが表示された場合、たとえ些細なことであっても、パニックを_回避_する方法をすぐに考えるべきです。

3. 最後のポイントから便乗して、 panicを呼び出しにネストすることはできないため、さらに見やすくなります。

プログラムの流れを制御することは非常に簡単であり、それが何をするかについて直感的であるため、パニックが発生しても問題ありません。

try関数は、これらの点のいずれも満たしていません。

1. $＃$ 10 $＃$のドキュメントを調べないと、 tryが何をするのかを推測することはできません。 多くの言語はキーワードをさまざまな方法で使用しているため、囲碁での意味を理解するのは困難です。

2. tryは、特に関数の場合、私の目に留まりません。 _特に_構文の強調表示が関数として強調表示される場合。 _ESPECIALLY_ Javaのような言語で開発した後、 tryは不要な定型文と見なされます（例外がチェックされているため）。

3. tryは、前のコメントproc := try(os.FindProcess(try(strconv.Atoi(os.Args[1]))))の例のように、関数呼び出しの引数で使用できます。 これにより、発見がさらに困難になります。

私の目は、特にそれらを探しているときでさえ、 try関数を無視します。 私の目はそれらを見るでしょうが、すぐにos.FindProcessまたはstrconv.Atoiの呼び出しにスキップします。 tryは条件付きの戻り値です。 制御フローとリターンはどちらもGoのペデスタルで保持されます。 関数内のすべての制御フローはインデントされ、すべての戻り値はreturnで始まります。 これらの概念の両方を混ぜ合わせて、見逃しやすい関数呼び出しにすると、少し気分が悪くなります。

しかし、このコメントと私の最後のコメントは、このアイデアに対する私の唯一の本当の批判です。 私はこの提案が気に入らなかったので外れるかもしれないと思いますが、それでもそれは囲碁にとって全体的な勝利だと思います。 このソリューションは、他のソリューションよりもGoに似ていると感じます。 これを追加していただければ幸いですが、それでも改善できると思いますので、どうすればいいのかわかりません。

@buchanaeおもしろい。 ただし、記述されているように、fmtスタイルのフォーマットをパッケージから言語自体に移動し、ワームの缶を開きます。

ただし、記述されているように、fmtスタイルのフォーマットをパッケージから言語自体に移動し、ワームの缶を開きます。

いい視点ね。 より簡単な例：

a, b, err := myFunc()
check(err, "calling myFunc")

@buchanae明示的なエラー処理をtryとより直接的に関連付けることを検討しました。詳細な設計ドキュメント、特に設計の反復に関するセクションを参照してください。 checkの具体的な提案では、私が正しく理解していれば、APIのようなfmt.Errorf （ checkの一部として）のようなものを介してのみエラーを増やすことができます。 一般に、エラー文字列を介して元の文字列を参照する新しいものを作成するだけでなく、エラーを使用してあらゆる種類のことを実行したい場合があります。

繰り返しますが、この提案はすべてのエラー処理状況を解決しようとはしていません。 ほとんどの場合、 tryは、基本的に次のようになっているコードには意味があると思います。

a, b, c, ... err := try(someFunctionCall())
if err != nil {
   return ..., err
}

このように見えるコードは非常にたくさんあります。 そして、このように見えるすべてのコードがより多くのエラー処理を必要とするわけではありません。 また、 deferが正しくない場合でも、 ifステートメントを使用できます。

私はこの行に従わない：

defer fmt.HandleErrorf(&err, “foobar”)

それは床にインバウンドエラーを落としますが、これは珍しいことです。 このようなものを使用するためのものですか？

defer fmt.HandleErrorf(&err, “foobar: %v”, err)

エラーの重複は少し途方に暮れています。 これは実際には提案に直接適切ではなく、ドキュメントに関するサイドコメントにすぎません。

@buchanaeによって提起された2つの懸念、re：名前付きリターンとコンテキストエラーを共有します。

名前付きの戻り値は、そのままでは少し面倒です。 それらはドキュメンテーションとしてのみ本当に有益だと思います。 それらにもっと大きく寄りかかるのは心配です。 でも、あいまいになってすみません。 これについてもっと考えて、もっと具体的な考えを提供します。

tryを使用できるようにコードを構造化して、エラーにコンテキストを追加しないようにすることが本当に懸念されていると思います。 公式のエラーラッピング機能を使用してエラーにコンテキストを追加するためのより良い方法を提供していることを考えると、これを紹介するのは特に奇妙な時期です。

提案されたtryは、いくつかのコードを非常に優れたものにすると思います。 これは、現在のプロジェクトのコードベースから多かれ少なかれランダムに選択した関数です。名前の一部が変更されています。 構造体フィールドに割り当てるときにtryがどのように機能するかに特に感銘を受けました。 （それは、私の提案の読み方が正しいこと、そしてこれが機能することを前提としていますか？）

既存のコード：

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        err := dbfile.RunMigrations(db, dbMigrations)
        if err != nil {
                return nil, err
        }
        t := &Thing{
                thingy: thingy,
        }
        t.scanner, err = newScanner(thingy, db, client)
        if err != nil {
                return nil, err
        }
        t.initOtherThing()
        return t, nil
}

try ：

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        try(dbfile.RunMigrations(db, dbMigrations))
        t := &Thing{
                thingy:  thingy,
                scanner: try(newScanner(thingy, db, client)),
        }
        t.initOtherThing()
        return t, nil
}

newScannerが失敗する可能性があることがあまり明白でないことを除いて、読みやすさを失うことはありません。 しかし、 try Goのある世界では、プログラマーはその存在にもっと敏感になるでしょう。

@josharian mainがerror $を返すことについて：同じ効果を得るのに必要なのは、あなたの小さなヘルパー関数だけのようです。 mainの署名を変更することが正当化されるかどうかはわかりません。

「foobar」の例について：これは悪い例です。 私はおそらくそれを変更する必要があります。 それを持ってきてくれてありがとう。

defer fmt.HandleErrorf(&err, “foobar: %v”, err)

errの評価が早すぎるため、実際にはそれは正しくありません。 これを回避する方法はいくつかありますが、元の（欠陥があると思う）HandleErrorfほどクリーンな方法はありません。 より現実的な実例を1つか2つのヘルパー関数があればいいと思います。

編集：この初期評価のバグは例に存在します
ドキュメントの終わり近く：

defer fmt.HandleErrorf(&err, "copy %s %s: %v", src, dst, err)

@adgはい、 tryは、例で使用しているとおりに使用できます。 私はあなたのコメントを再させます：名前付きの返品は現状のままです。

エラー文字列を介して元の文字列を参照する新しいものを作成するだけでなく、エラーを使用してあらゆる種類のことを実行したい場合があります。

tryは、エラーに対して人々がやりたいと思うすべての種類のことを処理しようとするのではなく、大幅に単純化するための実用的な方法を見つけることができるものだけを処理します。 私のcheckの例も同じように進んでいると思います。

私の経験では、エラー処理コードの最も一般的な形式は、基本的にスタックトレースを追加するコードであり、コンテキストが追加されることもあります。 スタックトレースはデバッグにとって非常に重要であることがわかりました。ここでは、コード全体でエラーメッセージを追跡します。

しかし、おそらく他の提案がすべてのエラーにスタックトレースを追加するでしょうか？ 道に迷った。

@adgが示した例では、2つの潜在的な障害がありますが、コンテキストはありません。 newScannerとRunMigrations自体が、どちらが間違っているかを示すメッセージを提供しない場合は、推測する必要があります。

@adgが示した例では、2つの潜在的な障害がありますが、コンテキストはありません。 newScannerとRunMigrations自体が、どちらが間違っているかを示すメッセージを提供しない場合は、推測する必要があります。

そうです、それがこの特定のコードで行った設計上の選択です。 コードの他の部分でエラーを頻繁にラップします。

@deanveloperや他の人たちと同じように、デバッグが難しくなるかもしれないという懸念を共有しています。 使用しないことを選択できるのは事実ですが、サードパーティの依存関係のスタイルは私たちの管理下にはありません。
繰り返しの少ないif err := ... { return err }が主要なポイントである場合、 https：//github.com/golang/go/issues/27794が提案しているように、「条件付きリターン」で十分かどうか疑問に思います。

        return nil, err if f, err := os.Open(...)
        return nil, err if _, err := os.Write(...)

?はtryよりも適していると思います。また、エラーのために常にdeferを追跡しなければならないことも注意が必要です。

これにより、 try/catch永久に使用する例外が発生した場合のゲートも閉じられます。

これにより、try / catchを永久に使用して例外が発生した場合のゲートも閉じられます。

私はこれで大丈夫です。

エラーにコンテキストを追加することに関して上記で提起された懸念のいくつかに同意します。 エラーを返すだけでなく、常にコンテキストで装飾してから返すように、ゆっくりと移行しようとしています。 この提案では、名前付きの戻りパラメータを使用するように関数を完全に変更する必要があります（裸の戻りをほとんど使用しないため、奇妙に感じます）。

@griesemerが言うように：

繰り返しますが、この提案はすべてのエラー処理状況を解決しようとはしていません。 ほとんどの場合、基本的に次のようになっているコードを試してみるのは理にかなっていると思います。
a、b、c、... err：= try（someFunctionCall（））
err！= nil {の場合
戻る...、エラー
}
このように見えるコードは非常にたくさんあります。 そして、このように見えるすべてのコードがより多くのエラー処理を必要とするわけではありません。 また、deferが正しくない場合でも、ifステートメントを使用できます。

はい、しかし良いことではありませんが、慣用的なコードは常にエラーをラップ/装飾しますか？ それが、stdlibにコンテキスト/ラップエラーを追加するための洗練されたエラー処理メカニズムを導入している理由だと思います。 私が見るように、この提案は最も基本的なユースケースのみを考慮しているようです。

さらに、この提案は、延期呼び出しで名前付きパラメーターを使用して、_単一の場所_で複数の可能なエラー戻りサイトをラップ/装飾する場合のみを扱います。

ただし、単一の関数でさまざまなエラーにさまざまなコンテキストを追加する必要がある場合は、何もしません。 たとえば、DBエラーを装飾して、エラーの発生元に関する詳細情報を取得することが非常に重要です（スタックトレースがないと仮定）。

これは私が持っている実際のコードの例です-

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    if err != nil {
        return err
    }
    var res int64
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    if err != nil {
        tx.Rollback()
        return fmt.Errorf("insert table: %w", err)
    }

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    if err != nil {
        tx.Rollback()
        return fmt.Errorf("insert table2: %w", err)
    }
    return tx.Commit()
}

提案によると：

エラーの増大またはラッピングが必要な場合は、2つのアプローチがあります。実証済みのifステートメントを使用するか、またはdeferステートメントを使用してエラーハンドラーを「宣言」します。

これは「実証済みのifステートメントに固執する」というカテゴリーに分類されると思います。 これにも対処するために提案を改善できることを願っています。

Goチームがジェネリックスを優先することを強くお勧めします。これは、Goが最も批判を聞く場所であり、エラー処理を待つためです。 今日のテクニックはそれほど苦痛ではありません（ go fmtはそれを一列に並べる必要があります）。

try()の概念には、チェック/ハンドルからのcheckのすべての問題があります。

1. Goのようには読めません。 人々は、Goのように見えるので、後続のnilテストなしで代入構文を望んでいます。 チェック/処理に対する13の個別の応答がこれを示唆しました。 ここで_定期的なテーマ_を参照してください：
   https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes

   f, #      := os.Open(...) // return on error
   f, #panic := os.Open(...) // panic on error
   f, #hname := os.Open(...) // invoke named handler on error
   // # is any available symbol or unambiguous pair
   

2. エラーを返す関数呼び出しをネストすると、操作の順序がわかりにくくなり、デバッグが妨げられます。 エラーが発生したときの状況、つまり呼び出しシーケンスは明確である必要がありますが、ここではそうではありません。
   try(step4(try(step1()), try(step3(try(step2())))))
   ここで、言語が禁止していることを思い出してください。
   f(t ? a : b)およびf(a++)

3. コンテキストなしでエラーを返すのは簡単です。 チェック/ハンドルの主な理由は、コンテキスト化を促進することでした。

4. これは、タイプerrorと最後の戻り値に関連付けられています。 他の戻り値/タイプの例外状態を検査する必要がある場合は、 if errno := f(); errno != 0 { ... }に戻ります。

5. 複数の経路を提供していません。 ストレージまたはネットワークAPIを呼び出すコードは、誤った入力や予期しない内部状態によるエラーとは異なる方法でこのようなエラーを処理します。 私のコードは、これらの1つをreturn errよりもはるかに頻繁に実行します。

   • log.Fatal（）
   • 発生してはならないエラーの場合はpanic（）
   • メッセージをログに記録して再試行してください

@gopherbot add Go2、LanguageChange

rustのように、 ?だけを使用して結果をアンラップするのはどうですか

try（）の呼び出しに懐疑的な理由は、2つの暗黙的なバインディングである可能性があります。 戻り値エラーのバインディングとtry（）の引数を確認できません。 try（）については、戻り値にエラーがある引数関数でtry（）を使用する必要があるというルールを作成できます。 しかし、戻り値へのバインドはそうではありません。 したがって、ユーザーがこのコードの機能を理解するには、より多くの表現が必要だと思います。

func doSomething() (int, %error) {
  f := try(foo())
  ...
}

• doSomethingの戻り値に%errorが含まれていない場合、try（）を使用することはできません。
• foo（）の最後の戻り値にエラーがない場合、try（）を使用することはできません。

既存の構文に新しい要件/機能を追加することは困難です。

正直なところ、foo（）にも％errorが必要だと思います。

ルールをもう1つ追加

• ％errorは、関数の戻り値リストで1つだけにすることができます。

詳細な設計ドキュメントで、以前の反復で、try組み込み関数にエラーハンドラーを渡すことが提案されていることに気付きました。 このような：

handler := func(err error) error {
        return fmt.Errorf("foo failed: %v", err)  // wrap error
}

f := try(os.Open(filename), handler)  

またはさらに良い、このように：

f := try(os.Open(filename), func(err error) error {
        return fmt.Errorf("foo failed: %v", err)  // wrap error
})  

ドキュメントに記載されているように、これはいくつかの疑問を提起しますが、このようなエラーハンドラ関数またはクロージャをオプションで指定する可能性を維持していれば、この提案ははるかに望ましく、有用であると思います。

第二に、関数が戻る原因となる可能性のある組み込みが気になりませんが、少し自転車に乗るには、「try」という名前は短すぎて、戻る可能性があることを示唆できません。 したがって、 attemptのような長い名前の方が私には適しているようです。

編集：第3に、理想的には、go言語は最初にジェネリックスを取得する必要があります。重要なユースケースは、このtry関数をジェネリックスとして実装できることです。これにより、バイクシェディングを終了でき、誰もが自分の好みのエラー処理を取得できます。

ハッカーニュースにはいくつかのポイントがあります。 tryは通常の関数のように動作しない（戻ることができる）ので、関数のような構文を与えるのは良くありません。 returnまたはdefer構文の方が適切です。

func CopyFile(src, dst string) (err error) {
        r := try os.Open(src)
        defer r.Close()

        w := try os.Create(dst)
        defer func() {
                w.Close()
                if err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        try io.Copy(w, r)
        try w.Close()
        return nil
}

@sheerunこれに対する一般的な反論は、 panicも制御フローを変更する組み込み関数であるということです。 私は個人的にそれに同意しませんが、それは正しいです。

1. 上記の@deanveloperや他の人の同様のコメントを反映して、新しい、やや微妙な、特に他の関数呼び出しにインライン化された場合に、呼び出しスタック制御を管理する簡単に見落とされがちなキーワードを追加するコストを過小評価していることを非常に恐れています。フロー。 panic(...)は、 returnが関数から抜け出す唯一の方法であるという規則に対する比較的明確な例外です（しゃれは意図されていません）。 3分の1を追加する正当な理由としてその存在を使用するべきではないと思います。
2. この提案では、ラップされていないエラーをデフォルトの動作として返すことを正規化し、追加のセレモニーを使用して、ラップエラーをオプトインする必要があるものとして委任します。 しかし、私の経験では、それは正確に良い習慣に逆行しています。 この分野での提案により、エラーサイトのエラーにコンテキスト情報を追加することがより簡単になるか、少なくとも難しくはないことを願っています。

このセマンティクスを使用して、 tryfのようなオプションの拡張関数を使用してバリアントを追加できる可能性があります。

func tryf(t1 T1, t1 T2, … tn Tn, te error, fn func(error) error) (T1, T2, … Tn)

これを翻訳します

x1, x2, … xn = tryf(f(), func(err error) { return fmt.Errorf("foobar: %q", err) })

これに

t1, … tn, te := f()
if te != nil {
    if fn != nil {
        te = fn(te)
    }
    err = te
    return
}

これは（ tryを使用する代わりに）明示的な選択であるため、この設計の以前のバージョンの質問に対する妥当な回答を見つけることができます。 たとえば、拡張関数がnilの場合、何もせずに元のエラーを返すだけです。

tryが従来のエラー処理に取って代わり、結果としてエラーパスへの注釈付けがより困難になるのではないかと心配しています。

メッセージをログに記録し、テレメトリカウンターを更新することでエラーを処理するコードは、すべてをtryすることを期待しているリンターと開発者の両方から、欠陥があるか不適切であると見なされます。

a, b, err := doWork()
if err != nil {
  updateCounters()
  writeLogs()
  return err
}

Goは非常に社交的な言語であり、ツール（fmt、lintなど）によって一般的なイディオムが適用されます。 このアイデアの社会的影響を念頭に置いてください-どこでもそれを使いたいと思う傾向があります。

@politician 、申し訳ありませんが、あなたが探している言葉は_social_ではなく_opinionated_です。 Goは独創的なプログラミング言語です。 残りの部分については、私はあなたが得ているものにほとんど同意します。

Godepやさまざまなリンターのような@beoranコミュニティツールは、Goが意見があり、社会的であり、言語を使用したドラマの多くがその組み合わせに由来することを示しています。 うまくいけば、私たちは両方ともtryが次のドラマであってはならないことに同意することができます。

@politician明確にしてくれてありがとう、私はそれをそのように理解していませんでした。 ドラマを避けようとするべきだということには確かに同意できます。

私はそれについて混乱しています。

ブログから：エラーは値です。私の観点からは、無視されないように評価されるように設計されています。

そして、Rop Pikeが言ったことは、「値をプログラムすることができ、エラーは値であるため、エラーをプログラムすることができる」と信じています。

errorをexceptionと見なすべきではありません。それは、思考だけでなく、コーディングのためにも複雑さをインポートするようなものです。

「この言語を使用して、エラー処理を簡素化してください。」 -ロブパイク

さらに、このスライドを確認できます

ifを介したエラーチェックが特に厄介な状況の1つは、ファイルを閉じるときです（NFSなど）。 .Close()からエラーが返される可能性がある場合、現在、次のように記述していると思います。

r, err := os.Open(src)
if err != nil {
    return err
}
defer func() {
    // maybe check whether a previous error occured?
    return r.Close()
}()

defer try(r.Close())は、そのようなエラーを処理するための管理可能な構文を持つための良い方法でしょうか？ 少なくとも、 r.Close()とw.Close()からのエラーを無視しないように、提案のCopyFile()の例を何らかの方法で調整することは理にかなっています。

@seehuhn遅延関数には戻り型がないため、例はコンパイルされません。

func doWork() (err error) {
  r, err := os.Open(src)
  if err != nil {
    return err
  }
  defer func() {
    err = r.Close()  // overwrite the return value
  }()
}

期待どおりに動作します。 キーは名前付きの戻り値です。

私は提案が好きですが、 @ seehuhnの例も同様に対処する必要があると思います：

defer try(w.Close())

エラーがまだ設定されていない場合にのみ、Close（）からエラーを返します。
このパターンはとても頻繁に使用されます...

エラーにコンテキストを追加することに関する懸念に同意します。 これは、エラーメッセージを非常にわかりやすく（そして明確に）保ち、デバッグプロセスを容易にするベストプラクティスの1つだと思います。

私が最初に考えたのは、 fmt.HandleErrorfをtryf関数に置き換えることでした。この関数は、エラーの前に追加のコンテキストを付けます。

func tryf(t1 T1, t1 T2, … tn Tn, te error, ts string) (T1, T2, … Tn)

たとえば（私が持っている実際のコードから）：

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil {
        return nil, errors.WithMessage(err, "load config dir")
    }
    b := bytes.NewBuffer(nil)
    if err = templates.ExecuteTemplate(b, "main", c); err != nil {
        return nil, errors.WithMessage(err, "execute main template")
    }
    buf, err := format.Source(b.Bytes())
    if err != nil {
        return nil, errors.WithMessage(err, "format main template")
    }
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    if err := ioutil.WriteFile(target, buf, 0644); err != nil {
        return nil, errors.WithMessagef(err, "write file %s", target)
    }
    // ...
}

次のように変更できます。

func (c *Config) Build() error {
    pkgPath := tryf(c.load(), "load config dir")
    b := bytes.NewBuffer(nil)
    tryf(emplates.ExecuteTemplate(b, "main", c), "execute main template")
    buf := tryf(format.Source(b.Bytes()), "format main template")
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    tryf(ioutil.WriteFile(target, buf, 0644), fmt.Sprintf("write file %s", target))
    // ...
}

または、 @ agnivadeの例をとると：

func (p *pgStore) DoWork() (err error) {
    tx := tryf(p.handle.Begin(), "begin transaction")
        defer func() {
        if err != nil {
            tx.Rollback()
        }
    }()
    var res int64
    tryf(tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res), "insert table")
    _, = tryf(tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res), "insert table2")
    return tryf(tx.Commit(), "commit transaction")
}

しかし、 @ josharianは、この解決策に躊躇する良い点を提起しました。

ただし、記述されているように、fmtスタイルのフォーマットをパッケージから言語自体に移動し、ワームの缶を開きます。

私はこの提案に完全に賛成しており、多くの例でその利点を見ることができます。

この提案に関する私の唯一の懸念は、 tryの命名です。他の言語との関係は、他の言語から来たときの目的についての開発者の認識を歪める可能性があると感じています。 Javaがここで見つかります。

私にとっては、ビルトインをpassと呼ぶ方がいいと思います。 これにより、何が起こっているのかをよりよく表すことができると思います。 結局のところ、エラーを処理しているのではなく、呼び出し元が処理できるようにエラーを返します。 tryは、エラーが処理されたという印象を与えます。

これは、主に、対処しようとしている問題（「通常、エラー処理に関連するステートメントの定型文」）が私にとって問題ではないため、私からは不満です。 すべてのエラーチェックが単純にif err != nil { return err }である場合、そのためにシンタックスシュガーを追加することに何らかの価値があります（ただし、Goは傾向によって比較的シュガーフリーの言語です）。

実際、nil以外のエラーが発生した場合に私がやりたいことは、状況によってかなり異なります。 たぶん私はt.Fatal(err)したいです。 飾るメッセージreturn fmt.Sprintf("oh no: %v", err)を追加したいのかもしれません。 たぶん、エラーをログに記録して続行します。 たぶん、SafeWriterオブジェクトにエラーフラグを設定して続行し、一連の操作の最後にフラグをチェックします。 多分私は他の行動を取る必要があります。 これらはいずれもtry自動化できません。 したがって、 tryの引数が、すべてのif err != nilブロックを削除するというものである場合、その引数は有効ではありません。

それらの_一部_を排除しますか？ もちろん。 それは私にとって魅力的な提案ですか？ まあ。 私は本当に心配していません。 私にとって、 if err != nilは、中括弧やdeferのように、Goの一部にすぎません。 Goを初めて使用する人にとっては冗長で反復的に見えることは理解していますが、Goを初めて使用する人は、さまざまな理由から、言語を劇的に変更するのに最適な場所ではありません。

Goの大幅な変更の基準は、従来、提案された変更は、（A）重要であり、（B）多くの人々に影響を及ぼし、（C）提案によって十分に解決される問題を解決する必要があるというものでした。 私はこれらの3つの基準のいずれにも確信が持てません。 Goのエラー処理はそのままでとても満足しています。

@peterbourgonと@deanveloperをエコーするために、Goについての私のお気に入りの1つは、コードフローが明確であり、panic（）がPythonのように標準のフロー制御メカニズムのように扱われないことです。

パニックに関する議論に関しては、パニック（）は価値がないため、ほとんどの場合、単独で行に表示されます。 fmt.Println(panic("oops"))はできません。 これにより、その可視性が大幅に向上し、人々が考えているよりもはるかにtry()に匹敵するものになります。

関数用に別のフロー制御構造がある場合は、それが行の左端の項目であることが保証されているステートメントであることが_far_になります。

提案の例の1つは、私にとって問題を突き止めます。

func printSum(a, b string) error {
        fmt.Println(
                "result:",
                try(strconv.Atoi(a)) + try(strconv.Atoi(b)),
        )
        return nil
}

制御フローは実際にはあまり目立たなくなり、非常にあいまいになります。

これは、すべてのエラーを明示的に処理する必要があるというRobPikeの当初の意図にも反しています。

これに対する反応は「それでは使用しない」ことですが、問題は、他のライブラリがそれを使用し、デバッグ、読み取り、使用がより問題になることです。 これにより、私の会社はgo 2を採用せず、 tryを使用しないライブラリのみを使用し始めるようになります。 私がこれだけではない場合、それは除算a-la python2 / 3につながる可能性があります。

また、 tryの名前は、最終的にcatchが構文に表示されることを自動的に意味し、Javaに戻ります。

ですから、これらすべてのために、私はこの提案に_強く_反対しています。

tryの名前が好きではありません。 これは、失敗のリスクが高い何かをしようとする_試み_を意味します（私は英語を母国語としないため、_try_に対して文化的な偏見があるかもしれません）が、まれな失敗が予想される場合は、代わりにtryが使用されます（エラー処理の冗長性を減らしたいという動機）そして楽観的です。 さらに、この提案のtryは、実際にはエラーを_キャッチ_して早期に返します。 @HiImJCのpassの提案が好きです。

名前のほかに、 returnのようなステートメントが式の途中に隠されているのは気まずいです。 これはGoフロースタイルを壊します。 コードレビューが難しくなります。

一般に、この提案は、コードを短くするための武器を持ち、エラーをラップする努力をする理由がさらに少ない怠惰なプログラマーにのみ利益をもたらすことがわかります。 また、レビューが難しくなる（表現の途中で戻る）ので、この提案は囲碁の「大規模なプログラミング」の目的に反すると思います。

言語を説明するときに私が一般的に言うGoについての私のお気に入りの1つは、ほとんどの場合、物事を行う方法は1つしかないということです。 この提案は、同じことを行うための複数の方法を提供することにより、その原則に少し反しています。 私は個人的に、これは必要ではなく、言語の単純さと読みやすさを増すのではなく、取り除くだろうと思います。

私は全体的にこの提案が好きです。 deferとの相互作用は、追加のコンテキストを追加しながら、エラーを返す人間工学的な方法を提供するのに十分であるように思われます。 @josharianが、ラップされたエラーメッセージに元のエラーを含める方法について指摘した問題に対処するのは良いことですが。

欠けているのは、これがテーブル上のエラー検査提案と相互作用する人間工学的な方法です。 APIは、どのタイプのエラーを返すかについて非常に慎重に検討する必要があり、デフォルトはおそらく「返されたエラーはまったく検査できない」はずです。 そうすれば、関数シグニチャによって文書化されているように、エラーを正確に検査できる状態に簡単に移行できるはずです（「状況Aでは種類Xのエラーを報告し、状況Bでは種類Yのエラーを報告します」）。

残念ながら、現時点では、この提案は最も人間工学的なオプションを（私にとって）最も望ましくないものにします。 任意のエラーの種類を盲目的に通過します。 これは、返されるエラーの種類やAPIのユーザーがそれらをどのように消費するかについて考えないようにするため、望ましくないと思います。 この提案の追加された利便性は確かに素晴らしいですが、あなたが提供する（またはリークする）エラー情報について慎重に考えることの知覚される価値よりも、知覚される利便性が知覚される価値を上回るため、悪い行動を助長するのではないかと思います。

絆創膏は、 tryによって返されたエラーが、「ラップ不可」ではないエラーに変換される場合に発生します。 残念ながら、これにはかなり深刻な欠点もあります。これは、 deferがエラー自体を検査できなくなるためです。 さらに、 tryが実際に望ましい種類のエラーを返すユースケース（つまり、 tryが不注意ではなく慎重に使用されるユースケース）を防ぎます。

別の解決策は、そのサイトから返される可能性のあるエラーの種類を定義/ホワイトリストに登録するために、オプションの2番目の引数をtryにするという（破棄された）アイデアを再利用することです。 「エラーの種類」を定義する方法が2つあり、値（ io.EOFなど）またはタイプ（ *os.PathError 、 *exec.ExitError ）のいずれかであるため、これは少し厄介です。 関数の引数として値であるエラーの種類を指定するのは簡単ですが、型を指定するのは困難です。 それをどのように処理するかはわかりませんが、アイデアをそこに投げ出します。

@josharianが指摘した問題は、errの評価を遅らせることで回避できます。

defer func() { fmt.HandleErrorf(&err, "oops: %v", err) }()

見栄えは良くありませんが、機能するはずです。 ただし、エラーポインター、または一般的なポインターの新しいフォーマット動詞/フラグを追加することでこれに対処できる場合は、プレーンな%vのように逆参照された値を出力することをお勧めします。 例の目的のために、それを%*vと呼びましょう：

defer fmt.HandleErrorf(&err, "oops: %*v", &err)

障害はさておき、この提案は有望に見えると思いますが、エラーにコンテキストを追加する人間工学を抑えることが重要であるように思われます。

編集：

別のアプローチは、 Stringerを実装する構造体でエラーポインタをラップすることです。

type wraperr struct{ err *error }
func (w wraperr) String() string { return (*w.err).Error() }

..。

defer handleErrorf(&err, "oops: %v", wraperr{&err})

私の観点からのいくつかのこと。 なぜ私たちは数行のコードを保存することをそれほど心配しているのですか？ 私はこれを、小さな関数が有害であると考えているのと同じ線に沿って考えています。

さらに、そのような提案は、私が心配しているいくつかの「魔法」のエラーを正しく処理する責任を取り除き、悪用されて怠惰を助長し、コードの品質が低下し、バグが発生することを発見しました。

述べられている提案には多くの不明確な振る舞いもあるので、これはより明確な_明示的な_余分な〜3行よりもすでに問題があります。

現在、社内では控えめなパターンを使用しています。 私たちが書いたときに同様に混合された受信を持っていた記事がここにあります-https：//bet365techblog.com/better-error-handling-in-go

ただし、 check / handleの提案が進行することを見越して使用しました。

チェック/処理は、エラー処理をより簡潔にするためのはるかに包括的なアプローチでした。 そのhandleブロックは、それが定義されたものと同じ関数スコープを保持していましたが、 deferステートメントは、いくらかのオーバーヘッドを伴う新しいコンテキストです。 これは、goのイディオムと一致しているように見えました。「エラーが発生したときにエラーを返すだけ」という動作が必要な場合は、明示的にhandle { return err }として宣言できます。

Deferは、明らかにerr参照が維持されていることに依存していますが、ブロックスコープの変数を使用してエラー参照をシャドウイングすると問題が発生することがわかりました。 したがって、goでエラーを処理する標準的な方法と見なされるほどの確実な方法ではありません。

この場合、 tryはあまり解決されていないようで、他の人と同じように、単に怠惰な実装や、延期パターンを使いすぎてしまう恐れがあります。

延期ベースのエラー処理がAThingになる場合は、次のようなものをエラーパッケージに追加する必要があります。

        f := try(os.Create(filename))
        defer errors.Deferred(&err, f.Close)

延期されたCloseステートメントのエラーを無視することは、かなり一般的な問題です。 それを助けるための標準的なツールがあるはずです。

戻る組み込み関数は、同じことを行うキーワードよりも売りにくいです。
Zig [1]のようなキーワードだったら、もっと欲しいです。

1. https://ziglang.org/documentation/master/#try

言語の型システムを使用して型署名を表現できず、その動作が関数の通常の動作を混乱させる組み込み関数は、実際の言語の進化を回避するために繰り返し使用できるエスケープハッチのように見えます。

この種の制御フローがGo（および他の多くの言語）で表現される方法であるため、returnステートメント（およびパニック）をすぐに認識するために使用されます。 リターンの場合と同じように、ある程度慣れた後、制御フローを変更することとしてtryも認識することはそれほど理解されていないようです。 優れたIDEサポートがこれにも役立つことは間違いありません。

かなり遠いところにあると思います。 gofmtされたコードでは、リターンは常に/^\t*return /と一致します。これは、支援なしで目で確認するのは非常に簡単なパターンです。 一方、 tryは、コード内のどこにでも発生する可能性があり、関数呼び出しの奥深くに任意にネストされます。 どんなに多くのトレーニングを行っても、ツールの支援なしに、関数内のすべての制御フローをすぐに見つけることができます。

さらに、「優れたIDEサポート」に依存する機能は、優れたIDEサポートがないすべての環境で不利になります。 コードレビューツールがすぐに思い浮かびます– Gerritは私のためにすべての試みを強調しますか？ さまざまな理由で、IDEや派手なコードの強調表示を使用しないことを選択した人はどうですか？ acmeはtryを強調し始めますか？

言語機能は、エディターのサポートに依存するのではなく、それ自体で理解しやすいものでなければなりません。

@kungfusheep私はその記事が好きです。 延期だけでラップすることに注意することは、 tryなしですでにかなり読みやすさを向上させます。

私は、Goのエラーが本当に問題だと感じていないキャンプにいます。 それでも、 if err != nil { return err }は、一部の関数でかなり途切れることがあります。 ほとんどすべてのステートメントの後にエラーチェックが必要な関数を作成しましたが、ラップとリターン以外の特別な処理は必要ありませんでした。 時々、物事をより良くする賢いBuffer構造体がないだけです。 時々それは次々と異なる重要なステップであり、何かがうまくいかなかった場合は単に短絡する必要があります。

tryは確かにそのコードをはるかに読みやすくし、完全な下位互換性を備えていますが、 tryは重要な機能ではないことに同意します。したがって、人々があまりにも恐れている場合は多分それを持っていないのが最善です。

ただし、セマンティクスは非常に明確です。 tryが表示されたときはいつでも、ハッピーパスをたどっているか、戻ってきます。 私は本当にそれよりも単純になることはできません。

これは、特殊なケースのマクロのように見えます。

@dominikh tryは常に/try\(/と一致するので、あなたのポイントが実際に何であるかはわかりません。 それは同様に検索可能であり、私が今まで聞いたすべての編集者は検索機能を持っています。

@qrpnxz彼が言いたかったのは、プログラムで検索できないということではなく、目で検索するのが難しいということだと思います。 正規表現は単なるアナロジーであり、 /^\t*に重点を置いており、すべてのリターンが行の先頭にあることで明らかに目立つことを意味します（先頭の空白を無視します）。

もっと考えてみると、いくつかの一般的なヘルパー関数があるはずです。 おそらく、それらは「据え置き」と呼ばれるパッケージに含まれている必要があります。

リターンに名前を付けないようにする形式でcheckの提案に対処するには、次のようにnilをチェックする関数を使用してこれを行うことができます。

func Format(err error, message string, args ...interface{}) error {
    if err == nil {
        return nil
    }
    return fmt.Errorf(...)
}

これは、次のように名前付きリターンなしで使用できます。

func foo(s string) (int, error) {
    n, err := strconv.Atoi(s)
    try(deferred.Format(err, "bad string %q", s))
    return n, nil
}

提案されたfmt.HandleErrorを代わりに遅延パッケージに入れて、エラーを発生させることができます。Deferヘルパーfuncをdeferred.Execと呼び、エラーがnil以外の場合にのみ実行するプロシージャの条件付きexecが存在する可能性があります。

まとめると、次のようなものが得られます

func CopyFile(src, dst string) (err error) {
    defer deferred.Annotate(&err, "copy %s %s", src, dst)

    r := try(os.Open(src))
    defer deferred.Exec(&err, r.Close)

    w := try(os.Create(dst))
    defer deferred.Exec(&err, r.Close)

    defer deferred.Cond(&err, func(){ os.Remove(dst) })
    try(io.Copy(w, r))

    return nil
}

もう一つの例：

func (p *pgStore) DoWork() (err error) {
    tx := try(p.handle.Begin())

    defer deferred.Cond(&err, func(){ tx.Rollback() })

    var res int64 
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    try(deferred.Format(err, "insert table")

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    try(deferred.Format(err, "insert table2"))

    return tx.Commit()
}

この提案により、どこにでもif err != nilがある状態から、どこにでもtryがある状態になります。 それは提案された問題をシフトし、それを解決しません。

ただし、現在のエラー処理メカニズムはそもそも問題ではないと私は主張します。 工具とその周りの検査を改善する必要があります。

さらに、 if err != nilは、ビジネスロジック言語の行を乱雑にするのではなく、そのすぐ下にあるため、実際にはtryよりも読みやすいと主張します。

file := try(os.OpenFile("thing")) // less readable than, 

file, err := os.OpenFile("thing")
if err != nil {

}

そして、もしGoがそのエラー処理においてもっと魔法のようであるなら、なぜそれを完全に所有しないのか。 たとえば、ユーザーがエラーを割り当てない場合、Goは組み込みのtryを暗黙的に呼び出すことができます。 例えば：

func getString() (string, error) { ... }

func caller() {
  defer func() {
    if err != nil { ... } // whether `err` must be defined or not is not shown in this example. 
  }

  // would call try internally, because a user is not 
  // assigning an error value. Also, it can add a compile error
  // for "defined and not used err value" if the user does not 
  // handle the error. 
  str := getString()
}

私にとって、それは実際には魔法と潜在的な可読性を犠牲にして冗長性の問題を達成するでしょう。

したがって、上記の例のように「問題」を真に解決するか、現在のエラー処理を維持することを提案しますが、冗長性とラッピングを解決するために言語を変更する代わりに、言語を変更せずに、ツールと検証を改善します経験をより良くするためのコードの。

たとえば、VSCodeにはiferrというスニペットがあり、入力してEnterキーを押すと、完全なエラー処理ステートメントに展開されます...したがって、これを書くのは面倒ではなく、後で読む方がよいでしょう。 。

@josharian

「ささやかなライブラリの変更」ではありませんが、func main（）エラーを受け入れることも検討できます。

それに関する問題は、すべてのプラットフォームがそれが何を意味するかについて明確なセマンティクスを持っているわけではないということです。 リライトは、完全なオペレーティングシステムで実行されている「従来の」Goプログラムでうまく機能しますが、マイクロコントローラーファームウェアまたはWebAssemblyだけを作成するとすぐに、 os.Exit(1)が何を意味するのかが明確になりません。 現在、 os.Exitはライブラリ呼び出しであるため、Goの実装は無料で提供されていません。 ただし、 mainの形は言語の問題です。

「いいえ」がおそらく最もよく答える提案についての質問： tryは可変個引数の引数とどのように相互作用しますか？ これは、最後の引数に可変個引数がない可変個引数（ish）関数の最初のケースです。 これは許可されていますか：

var e []error
try(e...)

なぜそうするのかはさておき。 答えは「いいえ」だと思います（そうでない場合は、「展開されたスライスの長さが0の場合はどうなりますか」。最終的に仕様を表現するときに覚えておくことができるように、それを提示するだけです。

• goの最大の機能のいくつかは、現在のビルトインが明確な制御フローを保証し、エラー処理が明示的で推奨されていること、そして開発者が「魔法の」コードを書くことを強く思いとどまらせていることです。 tryの提案は、制御フローの可読性を犠牲にして速記を促進するため、これらの基本的な信条と一致していません。
• この提案が採用された場合は、関数の代わりにtry組み込みステートメントを作成することを検討してください。 そうすれば、 ifのような他の制御フローステートメントとの整合性が高まります。 さらに、ネストされた括弧を削除すると、読みやすさがわずかに向上します。
• 繰り返しになりますが、提案が採用された場合は、おそらくdeferなどを使用せずに実装します。 （他の人が指摘しているように）それはすでに純粋なgoで実装することはできないので、内部でより効率的な実装を使用することもできます。

これには2つの問題があります。

1. たくさんのコードを関数内にネストします。 それはあなたの頭の中のコードを解析しようとして、多くの余分な認知的負荷を追加します。

1. これにより、コードがステートメントの途中から終了できる場所が得られます。

第二に、私ははるかに悪いと思います。 ここにあるすべての例は、エラーを返す単純な呼び出しですが、もっと陰湿なのはこれです。

func doit(abc string) error {
    a := fmt.Sprintf("value of something: %s\n", try(getValue(abc)))
    log.Println(a)
    return nil
}

このコードはそのsprintfの途中で終了する可能性があり、その事実を見逃しがちです。

私の投票はノーです。 これはgoコードをより良くすることはありません。 読みやすくなることはありません。 それはそれをより堅牢にすることはありません。

前にも言いましたが、この提案はそれを例示しています。Goに関する苦情の90％は、「ifステートメントやループを書きたくない」というものだと思います。 これにより、いくつかの非常に単純なifステートメントが削除されますが、認知的負荷が追加され、関数の出口点を見逃しやすくなります。

これをメインで使用することはできず、新しいユーザーや教えるときに混乱する可能性があることを指摘したいと思います。 明らかに、これはエラーを返さないすべての関数に当てはまりますが、多くの例に表示されるため、mainは特別だと思います。

func main() {
    f := try(os.Open("foo.txt"))
    defer f.Close()
}

メインでパニックを試してみるのも受け入れられるかどうかはわかりません。

さらに、残念なことに、テスト（ func TestFoo(t* testing.T) ）では特に役立ちません:(

これに関して私が抱えている問題は、エラーが発生したときに常にエラーを返したいと想定していることです。 エラーにコンテキストを追加して返す場合や、エラーが発生したときの動作を変えたい場合。 多分それは返されたエラーの種類に依存します。

私は次のように見えるかもしれないtry / catchに似たものを好むでしょう

foo()が次のように定義されていると仮定します

func foo() (int, error) {}

その後、あなたはすることができます

n := try(foo()) {
    case FirstError:
        // do something based on FirstError
    case OtherError:
        // do something based on OtherError
    default:
        // default behavior for any other error
}

これは

n, err := foo()
if errors.Is(err, FirstError) {
    // do something based on FirstError
if errors.Is(err, OtherError) {
    // do something based on OtherError
} else {
    // default behavior for any other error
}

私にとって、エラー処理はコードベースの最も重要な部分の1つです。
すでに多すぎるgoコードはif err != nil { return err }であり、余分なコンテキストを追加せずにスタックの深部からエラーを返します。さらに（おそらく）根本的なエラーをfmt.Errorfラッピングでマスクしてコンテキストを追加します。

if err != nil { return err }置き換えるだけの魔法のような新しいキーワードを提供することは、危険な道のように思えます。
これで、すべてのコードがtryの呼び出しにラップされます。 これは、次のようなパッケージ内のエラーのみを処理するコードの場合は多少問題ありません（ただし、読みやすさは悪くなります）。

func foo() error {
  /// stuff
  try(bar())
  // more stuff
}

しかし、与えられた例は本当に恐ろしいものであり、基本的に、呼び出し元は、例外処理のように、スタックの非常に深いエラーを理解しようとします。
もちろん、これはすべて開発者がここで正しいことを行うかどうかにかかっていますが、開発者は「後でこれを修正する」などのエラーを気にしないための優れた方法を提供します（そしてそれがどのように行われるかは誰もが知っています）。

*「繰り返しを減らすにはどうすればよいか」や「（適切な）エラー処理をより簡単にし、開発者の生産性を高めるにはどうすればよいか」とは別の観点から問題を検討したいと思います。
これが本番コードの実行にどのように影響するかを考える必要があります。

*注：これは実際には繰り返しを減らすものではなく、繰り返される内容を変更するだけですが、すべてがtry()に含まれているため、コードが読みにくくなります。

最後のポイント：最初に提案を読むのは良いことのように思えますが、それからすべての落とし穴（少なくともリストされているもの）に取り掛かり始めます。それは「わかりました、これは多すぎます」のようなものです。

これの多くは主観的なものだと思いますが、それは私が気にかけていることです。 これらのセマンティクスは非常に重要です。
私が見たいのは、POC /デモレベルのコードでもエラーを「正しく」実行できるように、本番レベルのコードの記述と保守を簡単にする方法です。

エラーコンテキストは繰り返し発生するテーマのようです...

仮説：ほとんどのGo関数は、 (T1, T2, T3, error)ではなく(T, error)を返します

tryをtry(T1, T2, T3, error) (T1, T2, T3) $として定義する代わりに、次のように定義した場合はどうなりますか
try(func (args) (T1, T2, T3, error))(T1, T2, T3) ？ （これは概算です）

つまり、 try呼び出しの構文構造は常に最初の引数であり、複数の値を返す式であり、最後の引数はエラーです。

次に、 makeと同様に、これにより2引数形式の呼び出しへの扉が開かれます。2番目の引数は試行のコンテキストです（たとえば、固定文字列、 %vの文字列）。

これにより、 (T, error)の場合でも連鎖が可能になりますが、IMOが通常必要としない複数の返品を連鎖させることはできなくなります。

@ cpuguy83提案を読むと、エラーをラップすることを妨げるものは何もないことがわかります。 実際、 tryを使用しながらそれを行うには複数の方法があります。 しかし、多くの人は何らかの理由でそれを想定しているようです。

if err != nil { return err }は、プロトタイピングの際の煩わしさを除けば、 try $と同じように「後で修正します」と同じです。

括弧のペアの内側にあるものが、ボイラープレートの4行ごとにある関数ステップよりも読みにくいこともわかりません。

それがトピックなので、あなたがあなたを悩ませたこれらの特定の「落とし穴」のいくつかを指摘するならば、それは素晴らしいでしょう。

読みやすさは問題のようですが、次のように、try（）を目立たせるためにfmtを提示するのはどうでしょうか。

f := try(
    os.Open("file.txt")
)

@MrTravisB

これに関して私が抱えている問題は、エラーが発生したときに常にエラーを返したいと想定していることです。

同意しません。 それは、あなたがそのための速記を正当化するのに十分な頻度でやりたいと思っていることを前提としています。 そうしないと、エラーをわかりやすく処理するのに邪魔になりません。

エラーにコンテキストを追加して返す場合や、エラーが発生したときの動作を変えたい場合。

この提案では、ブロック全体のコンテキストをエラーに追加するためのパターンについて説明しています。 @josharianは、例にエラーがあることを指摘しましたが、それを回避するための最善の方法は明確ではありません。 私はそれを処理する方法のいくつかの例を書きました。

より具体的なエラーコンテキストについても、 tryが機能します。そのことを望まない場合は、 tryを使用しないでください。

@boomlindeまさに私のポイント。 この提案は、エラー処理のより大きな問題を解決するためのツールを提供するのではなく、単一のユースケースを解決しようとしています。 正確にあなたが指摘したことなら、根本的な質問だと思います。

それは、あなたがそのための速記を正当化するのに十分な頻度でやりたいと思っていることを前提としています。

私の意見と経験では、このユースケースは少数派であり、省略構文を保証するものではありません。

また、 deferを使用してエラーを処理するアプローチには、考えられるすべてのエラーを同じように処理することを前提としているという問題があります。 deferステートメントはキャンセルできません。

defer fmt.HandleErrorf(&err, “foobar”)

n := try(foo())

x : try(foo2())

foo()とfoo2()から返される可能性のあるエラーに対して異なるエラー処理が必要な場合はどうなりますか？

@MrTravisB

foo（）とfoo2（）から返される可能性のあるエラーに対して異なるエラー処理が必要な場合はどうなりますか？

次に、他のものを使用します。 それが@boomlindeが言っていたポイントです。

個人的にこのユースケースを頻繁に目にすることはないかもしれませんが、多くの人が目にします。 tryを追加しても実際には影響はありません。 実際、ユースケースがまれであるほど、 tryが追加されることによる影響は少なくなります。

@qrpnxz

f := try(os.Open("/foo"))
data := try(ioutil.ReadAll(f))
try(send(data))

（はい、 ReadFileがあり、この特定の例は、ポイントではなく、どこかにデータをコピーするための最良の方法ではないことを理解しています）

tryのインラインを解析する必要があるため、これを読むのにさらに手間がかかります。 アプリケーションロジックは別の呼び出しでラップされます。
また、ここでのdeferエラーハンドラーは、エラーを新しいメッセージでラップする以外は適切ではないと主張します...これは素晴らしいことですが、エラーを簡単に処理することよりも、エラーを処理することの方が重要です。何が起こったのかを読む人間。

さびた場合、少なくとも演算子は接尾辞（呼び出しの最後に?が追加されます）であり、実際のロジックを掘り下げるために余分な負担をかけません。

式ベースのフロー制御

panicは別のフロー制御関数である可能性がありますが、値を返さないため、事実上ステートメントになります。 これをtryと比較してください。これは式であり、どこでも発生する可能性があります。

recoverには値があり、フロー制御に影響しますが、 deferステートメントで発生する必要があります。 これらのdeferは通常、関数リテラルであり、 recoverは一度だけ呼び出されるため、 recoverもステートメントとして効果的に発生します。 繰り返しますが、これをどこでも発生する可能性のあるtryと比較してください。

これらの点は、 tryを使用すると、以前に指摘したように、これまでにない方法で制御フローを追跡することが非常に困難になることを意味すると思いますが、ステートメントと式の違いはわかりませんでした。指摘した。

別の提案

次のようなステートメントを許可する

if err != nil {
    return nil, 0, err
}

ブロックにreturnステートメントのみが含まれ、そのステートメントに改行が含まれていない場合は、1行でgofmtでフォーマットされます。 例えば：

if err != nil { return nil, 0, err }

理論的根拠

• 言語の変更は必要ありません
• フォーマットルールはシンプルで明確です
• ルールは、 gofmtが（構造体リテラルのように）改行がすでに存在する場合に改行を保持するオプトインになるように設計できます。 オプトインにより、ライターはエラー処理を強調することもできます
• オプトインしていない場合は、 gofmtを呼び出すことで、コードを新しいスタイルに自動的に移植できます。
• returnステートメント専用なので、不必要にゴルフコードに悪用されることはありません
• いくつかのエラーが発生する理由と、エラーが返される理由を説明するコメントとうまく相互作用します。 多くのネストされたtry式を使用すると、これをうまく処理できません
• エラー処理の垂直方向のスペースを66％削減します
• 式ベースの制御フローなし
• コードは書かれているよりもはるかに頻繁に読み取られるため、読者向けに最適化する必要があります。 tryがライターに寄りかかる場合、より少ないスペースを占める反復コードはリーダーに役立ちます
• 人々はすでに複数の行に存在するtryを提案しています。 たとえば、このコメントまたは次のようなスタイルを紹介するこのコメント

f, err := os.Open(file)
try(maybeWrap(err))

• 「独自の行で試す」スタイルは、返されるerr値に関するあいまいさを取り除きます。 したがって、このフォームが一般的に使用されると思います。 ブロックがほぼ同じである場合に1行を許可することは、戻り値が何であるかについても明示されていることを除いてです。
• 名前付き返品の使用を促進したり、 deferベースのラッピングを不明確にしたりすることはありません。 どちらもラッピングエラーの障壁を高め、前者はgodocの変更が必要になる場合があります
• 従来のエラー処理を使用する場合と比較して、 tryを使用する場合について議論する必要はありません。
• 将来tryまたは他の何かをすることを排除しません。 tryが受け入れられたとしても、変化はプラスになる可能性があります
• testingライブラリまたはmain関数との負の相互作用はありません。 実際、提案が単なる戻り値ではなく単一行のステートメントを許可する場合、アサーションベースのライブラリの使用を減らす可能性があります。 検討

value, err := something()
if err != nil { t.Fatal(err) }

• 特定のエラーをチェックすることによる否定的な相互作用はありません。 検討

n, err := src.Read(buf)
if err == io.EOF { return nil }
else if err != nil { return err }

要約すると、この提案はコストが低く、オプトインするように設計でき、文体のみであるためそれ以上の変更を排除せず、すべてを明示的に保ちながら、冗長なエラー処理コードを読む手間を軽減します。 tryに入る前に、少なくとも最初のステップと見なす必要があると思います。

https://github.com/golang/go/issues/32437#issuecomment-498941435から

試してみて

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        try(dbfile.RunMigrations(db, dbMigrations))
        t := &Thing{
                thingy:  thingy,
                scanner: try(newScanner(thingy, db, client)),
        }
        t.initOtherThing()
        return t, nil
}

これとともに

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        err := dbfile.RunMigrations(db, dbMigrations))
        if err != nil { return nil, fmt.Errorf("running migrations: %v", err) }

        t := &Thing{thingy: thingy}
        t.scanner, err = newScanner(thingy, db, client)
        if err != nil { return nil, fmt.Errorf("creating scanner: %v", err) }

        t.initOtherThing()
        return t, nil
}

エラーにコンテキストを追加しながら、スペース使用量で競争力があります。

https://github.com/golang/go/issues/32437#issuecomment-499007288から

試してみて

func (c *Config) Build() error {
    pkgPath := try(c.load())
    b := bytes.NewBuffer(nil)
    try(emplates.ExecuteTemplate(b, "main", c))
    buf := try(format.Source(b.Bytes()))
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    try(ioutil.WriteFile(target, buf, 0644))
    // ...
}

これとともに

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil { return nil, errors.WithMessage(err, "load config dir") }

    b := bytes.NewBuffer(nil)
    err = templates.ExecuteTemplate(b, "main", c)
    if err != nil { return nil, errors.WithMessage(err, "execute main template") }

    buf, err := format.Source(b.Bytes())
    if err != nil { return nil, errors.WithMessage(err, "format main template") }

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    err = ioutil.WriteFile(target, buf, 0644)
    if err != nil { return nil, errors.WithMessagef(err, "write file %s", target) }
    // ...
}

元のコメントでは、架空のtryfを使用してフォーマットを添付しましたが、これは削除されています。 すべての個別のコンテキストを追加する最善の方法は不明であり、おそらくtryは適用できません。

@ cpuguy83
私にとっては、 tryの方が読みやすくなっています。 この例では、「ファイルを開き、すべてのバイトを読み取り、データを送信する」と読みます。 通常のエラー処理では、「ファイルを開き、エラーが発生したかどうかを確認し、エラー処理がこれを実行してから、すべてのバイトを読み取り、何かが発生したかどうかを確認します...」と読みます。 err != nilをスキャンできることはわかっています。 tryの方が簡単です。なぜなら、それを見るとすぐに動作がわかるからです。err！= nilの場合に戻ります。 あなたがブランチを持っているなら、私はそれが何をするかを見なければなりません。 それは何でもできます。

また、エラーを新しいメッセージでラップする以外は、ここでの遅延エラーハンドラーは適​​切ではないと主張します。

延期でできることは他にもあると思いますが、それでも、 tryは単純な一般的なケースです。 もっと何かをしたいときはいつでも、古き良きGoエラー処理が常にあります。 それはなくなることはありません。

@zeeboうん、私はそれに夢中です。
@kungfusheepの記事では、そのような1行のエラーチェックを使用していたので、試してみることにしました。 それから私が保存するとすぐに、gofmtはそれを3行に拡張しました。それは悲しいことでした。 stdlibの多くの関数は、そのように1行で定義されているので、gofmtがそれを拡張することに驚きました。

@qrpnxz

私はたまたまたくさんのgoコードを読んでいます。 この言語の最も優れている点の1つは、特定のスタイルに従ったほとんどのコードの使いやすさです（gofmtに感謝）。
try(f())でラップされたコードの束を読みたくありません。
これは、コードのスタイル/練習に相違があるか、「ここでtry()を使用すべきだった」のようなリンターがあることを意味します（これも私は好きではありません。これが私や他の人のコメントのポイントです。この提案について）。

客観的にはif err != nil { return err }よりも優れているわけではなく、入力するのが少ないだけです。

最後に一つだけ：

提案を読むと、あなたを妨げるものは何もないことがわかります

そのような言葉は控えてもらえますか？ もちろん私はその提案を読みました。 たまたま昨夜読んで、今朝考えてコメントしたのですが、意図したことの細かな点を説明していませんでした。
これは信じられないほど敵対的な口調です。

@ cpuguy83
私の悪いCPUの男。 私はそのようにそれを意味しませんでした。

また、 tryを使用するコードは、使用しないコードとはかなり異なって見えることを指摘する必要があると思います。そのため、そのコードの解析のエクスペリエンスに影響を与えると想像できますが、その違いに完全に同意することはできません。この場合はもっと悪いことを意味しますが、私が個人的に好きなのと同じように、あなたが個人的にそれを好きではないことは理解しています。 Goの多くのことはそのようです。 リンターがあなたに何をするように言うかについては、まったく別の問題だと思います。

確かにそれは客観的に良くはありません。 私はそれが私にとってより読みやすいことを表現していました。 私はそれを注意深く言いました。

繰り返しますが、そのように聞こえてすみません。 これは議論ですが、私はあなたに敵対するつもりはありませんでした。

https://github.com/golang/go/issues/32437#issuecomment -498908380

誰もあなたに試してもらうつもりはありません。

ざらざらしていることを無視すると、それはデザインに対する批判を却下するためのかなり手に負えない方法だと思います。

確かに、私はそれを使用する必要はありません。 しかし、私がコードを書く人は誰でもそれを使用して、 try(try(try(to()).parse().this)).easily())を解読しようと強制することができます。 それは言うようなものです

空のインターフェースを使用させる人は誰もいません{}。

とにかく、Goは単純さについてかなり厳密です。 gofmtを使用すると、すべてのコードが同じように見えます。 幸せな道は残されており、高価または驚くべきものはすべて明白です。 提案されているtryは、これから180度回転します。 シンプルさ！=簡潔。

少なくともtryは左辺値を持つキーワードである必要があります。

if err != nil { return err }よりも_客観的に_優れているわけではなく、入力するのが少ないだけです。

2つの間に1つの客観的な違いがあります： try(Foo())は式です。 一部の人にとっては、その違いは欠点です（ try(strconv.Atoi(x))+try(strconv.Atoi(y))の批判）。 他の人にとっては、その違いはほとんど同じ理由で良い面です。 それでも客観的に良くも悪くもありませんが、違いが敷物の下で一掃されるべきではないと私は思います、そしてそれが「タイプするのがちょうど少ない」と主張することは提案の正義を行いません。

@ elagergren-spideroakは、 tryが一息で見るのが面倒で、次の息では明示的ではないと言うのは難しいです。 あなたは1つを選ばなければなりません。

関数の引数が最初に一時変数に入れられるのを見るのは一般的です。 見るのがもっと一般的だと思います

this := try(to()).parse().this
that := try(this.easily())

あなたの例より。

try何もしないのは幸せな道なので、期待どおりに見えます。 不幸な道では、それがするのは戻ることだけです。 その情報を収集するには、 tryがあることを確認するだけで十分です。 関数から戻ることについても費用がかかることはないので、その説明から、 tryが180を実行しているとは思わない

@josharian https://github.com/golang/go/issues/32437#issuecomment -498941854でのコメントに関して、ここでは早期評価エラーはないと思います。

fmt.HandleErrorf（＆err、“ foobar：％v”、err）を延期します

変更されていないerr HandleErrorf渡され、 errへのポインタが渡されます。 errがnilであるかどうかを確認します（ポインターを使用）。 そうでない場合は、変更されていない値errを使用して文字列をフォーマットします。 次に、ポインタを使用して、フォーマットされたエラー値にerrを設定します。

@Merovius提案は実際には単なるシンタックスシュガーマクロなので、人々が見栄えが良くなるか、問題が最も少ないと思うものになるでしょう。 そう思わない場合は、私に説明してください。 だから私は個人的にそれを望んでいます。 私の観点からは、キーワードを追加しなくてもいい追加です。

@ ianlancetaylor 、 @ josharianは正しいと思います。 errの「変更されていない」値は、 deferがスタックにプッシュされたときの値であり、 errの（おそらく意図された）値ではありません。戻る前にtryによって設定されたerr 。

私がtryで抱えているもう一つの問題は、人々がより多くのロジックを1行にダンプするのが非常に簡単になることです。 これは、他のほとんどの言語での私の大きな問題です。1行に5つの式のように配置するのが非常に簡単であり、それを使いたくないということです。

this := try(to()).parse().this
that := try(this.easily())

^^これでもなんともひどいです。 最初の行は、頭の中でパレンマッチングを行って前後にジャンプする必要があります。 実際には非常に単純な2行目でさえ...本当に読みにくいです。
入れ子関数は読みにくいです。

parser, err := to()
if err != nil {
    return err
}
this := parser.parse().this
that, err := this.easily()
if err != nil {
    return err
}

^^これは非常に簡単で優れたIMOです。 とてもシンプルでクリアです。 はい、それはもっと多くのコード行です、私は気にしません。 それは非常に明白です。

@bcmills @josharianああ、もちろん、ありがとう。 だからそれは

defer func() { fmt.HandleErrorf(&err, “foobar: %v”, err) }()

あまり良くない。 たぶんfmt.HandleErrorfは、結局のところ、最後の引数としてエラー値を暗黙的に渡す必要があります。

この問題は非常に迅速に多くのコメントを受け取りました、そしてそれらの多くはすでになされたコメントを繰り返しているように私には思えます。 もちろんコメントもお気軽にどうぞ。すでに述べたポイントを言い換える場合は、ポイントを繰り返すのではなく、GitHubの絵文字を使用して行うことをお勧めします。 ありがとう。

@ianlancetaylor fmt.HandleErrorfがフォーマット後の最初の引数としてerrを送信すると、実装がより適切になり、ユーザーは常に%[1]vで参照できるようになります。

@natefinch絶対に同意します。

さび型のアプローチの方が口に合うのではないでしょうか。
これはただ考えているだけの提案ではないことに注意してください...

this := to()?.parse().this
that := this.easily()?

結局、これはもっと良いと思いますが（ !または他の何かを使用することもできます...）、それでもエラー処理の問題をうまく修正できません。

もちろん、錆もこのようにtry()を持っていますが、...他の錆のスタイルです。

if err != nil { return err }よりも_客観的に_優れているわけではなく、入力するのが少ないだけです。

2つの間に1つの客観的な違いがあります： try(Foo())は式です。 一部の人にとっては、その違いは欠点です（ try(strconv.Atoi(x))+try(strconv.Atoi(y))の批判）。 他の人にとっては、その違いはほとんど同じ理由で良い面です。 それでも客観的に良くも悪くもありませんが、違いが敷物の下で一掃されるべきではないと私は思います、そしてそれが「タイプするのがちょうど少ない」と主張することは提案の正義を行いません。

これが、私がこの構文を気に入っている最大の理由の1つです。 これにより、すべての中間結果に名前を付けることなく、より大きな式の一部としてエラーを返す関数を使用できます。 名前を付けるのが簡単な場合もありますが、特に意味のある名前や冗長性のない名前を付ける必要がない場合もあります。その場合は、名前をまったく付けたくありません。

@MrTravisB

まさに私のポイント。 この提案は、エラー処理のより大きな問題を解決するためのツールを提供するのではなく、単一のユースケースを解決しようとしています。 正確にあなたが指摘したことなら、根本的な質問だと思います。

それがまさにあなたのポイントだと私は具体的に何と言いましたか？ 私たちが同意すると思うなら、あなたは私の主張を根本的に誤解しているように私には思えます。

私の意見と経験では、このユースケースは少数派であり、省略構文を保証するものではありません。

Goソースには、エラーにコンテキストを追加する方法がなかったとしても、箱から出してtryで処理できるケースが何千もあります。 マイナーな場合でも、それは依然として一般的な苦情の原因です。

また、エラーを処理するためにdeferを使用するアプローチには、考えられるすべてのエラーを同じように処理することを前提としているという問題があります。 延期ステートメントはキャンセルできません。

同様に、+を使用して算術を処理するアプローチは、減算したくないことを前提としているため、減算しない場合は減算しません。 興味深い質問は、ブロック全体のエラーコンテキストが少なくとも一般的なパターンを表しているかどうかです。

foo（）とfoo2（）から返される可能性のあるエラーに対して異なるエラー処理が必要な場合はどうなりますか？

繰り返しますが、 tryは使用しません。 そうすれば、 tryから何も得られませんが、何も失うことはありません。

@ cpuguy83

さび型のアプローチの方が口に合うのではないでしょうか。

提案はこれに反対する議論を提示します。

この時点で、 try{}catch{}を使用する方が読みやすいと思います：upside_down_face：

1. 名前付きインポートを使用してdeferコーナーケースを回避することは、godocのようなものにとってひどいだけでなく、最も重要なことに、エラーが発生しやすいことです。 問題を回避するために、すべてを別のfunc()でラップできるかどうかは気にしません。覚えておく必要があるのはそれだけではなく、「悪い習慣」を助長すると思います。

2. 誰もあなたに試してもらうつもりはありません。

   それが良い解決策であるという意味ではありません。現在のアイデアには設計上の欠陥があることを強調し、エラーが発生しにくい方法で対処することを求めています。

3. try(try(try(to()).parse().this)).easily())のような例は非現実的だと思います。これは他の関数ですでに実行できているので、コードをレビューする人がコードを分割するように依頼するのは公平だと思います。

4. エラーが発生する可能性のある場所が3つあり、各場所を個別にラップしたい場合はどうなりますか？ try()はこれを非常に難しくします。実際、 try()は、その難しさを考えると、すでに折り返しエラーを思いとどまらせていますが、これが私の言いたいことの例です。

   func before() error {
     x, err := foo()
     if err != nil {
       wrap(err, "error on foo")
     }
     y, err := bar(x)
     if err != nil {
       wrapf(err, "error on bar with x=%v", x)
     }
     fmt.Println(y)
     return nil
   }
   
   func after() (err error) {
     defer fmt.HandleErrorf(&err, "something failed but I don't know where: %v", err)
     x := try(foo())
     y := try(bar(x))
     fmt.Println(y)
     return nil
   }
   

5. 繰り返しますが、 tryは使用しません。 そうすれば、 tryから何も得られませんが、何も失うことはありません。

   エラーを有用なコンテキストでラップすることは良い習慣だとしましょう。 try()はコンテキストを追加しないため、悪い習慣と見なされます。 これは、 try()が誰も使用したくない機能であり、ほとんど使用されないために存在しなかった可能性がある機能になることを意味します。

   「まあ、気に入らないのなら、使わないで黙って」と言うのではなく（こういう読み方です）、多くの人が欠陥を考えていることに対処してみたほうがいいと思います。デザインで。 代わりに、私たちの懸念がより良い方法で処理されるように、提案された設計から何を変更できるかについて話し合うことができますか？

@boomlinde私たちが同意する点は、この提案はマイナーなユースケースを解決しようとしているということであり、「必要がない場合は使用しない」という事実がその点を促進するための主要な議論です。 @ elagergren-spideroakが述べたように、私がそれを使いたくなくても、他の人が私にそれを使わざるをえないので、その議論はうまくいきません。 あなたの議論の論理によって、Goはまた三項ステートメントを持つべきです。 また、三項ステートメントが気に入らない場合は、使用しないでください。

免責事項-Goには三項ステートメントが必要だと思いますが、言語機能に対するGoのアプローチは、コードを読みにくくする可能性のある機能を導入しないことです。

別のことが私に起こります。 tryがあると、開発者が不注意にエラーを処理するようになるかもしれないという考えに基づいて、多くの批判があります。 しかし、私の意見では、これはどちらかといえば、現在の言語により当てはまります。 エラー処理の定型文は、それを回避するためにいくつかのエラーを飲み込むか無視することを奨励するほど厄介です。 たとえば、私はこのようなことを数回書いています：

func exists(filename string) bool {
  _, err := os.Stat(filename)
  return err == nil
}

このコードはいくつかの考えられるエラーを黙って無視しますが、 if exists(...) { ... }を書き込めるようにするためです。 tryがあった場合、おそらくそれを気にせず、 (bool, error)を返すだけです。

ここでは混沌としているので、 catchという2番目の組み込み関数を追加するというアイデアを投げかけます。この関数は、エラーを受け取り、上書きされたエラーを返す関数を受け取り、その後のcatchと呼ばれ、ハンドラーを上書きします。 例えば：

func catch(handler func(err error) error) {
  // .. impl ..
}

これで、この組み込み関数は、次のようにtryによって返される次のエラーを処理するマクロのような関数にもな​​ります。

func wrapf(format string, ...values interface{}) func(err error) error {
  // user defined
  return func(err error) error {
    return fmt.Errorf(format + ": %v", ...append(values, err))
  }
}
func sample() {
  catch(wrapf("something failed in foo"))
  try(foo()) // "something failed in foo: <error>"
  x := try(foo2()) // "something failed in foo: <error>"
  // Subsequent calls for catch overwrite the handler
  catch(wrapf("something failed in bar with x=%v", x))
  try(bar(x)) // "something failed in bar with x=-1: <error>"
}

これは、 deferなしでエラーをラップできるので便利です。これは、名前付きの戻り値を使用するか、別の関数でラップしない限り、エラーが発生しやすい可能性があります。また、 deferが同じエラーハンドラーを追加するので便利です。 2つを別の方法で処理したい場合でも、すべてのエラー。 次のように、適切と思われる方法で使用することもできます。

func foo(a, b string) (int64, error) {
  return try(strconv.Atoi(a)) + try(strconv.Atoi(b))
}
func withContext(a, b string) (int64, error) {
  catch(func (err error) error {
    return fmt.Errorf("can't parse a: %s, b: %s, err: %v", a, b, err)
  })
  return try(strconv.Atoi(a)) + try(strconv.Atoi(b))
}
func moreExplicitContext(a, b string) (int64, error) {
  catch(func (err error) error {
    return fmt.Errorf("can't parse a: %s, err: %v", a, err)
  })
  x := try(strconv.Atoi(a))
  catch(func (err error) error {
    return fmt.Errorf("can't parse b: %s, err: %v", b, err)
  })
  y := try(strconv.Atoi(b))
  return x + y
}
func withHelperWrapf(a, b string) (int64, error) {
  catch(wrapf("can't parse a: %s", a))
  x := try(strconv.Atoi(a))
  catch(wrapf("can't parse b: %s", b))
  y := try(strconv.Atoi(b))
  return x + y
}
func before(a, b string) (int64, error) {
  x, err := strconv.Atoi(a)
  if err != nil {
    return 0,  fmt.Errorf("can't parse a: %s, err: %v", a, err)
  }
  y, err := strconv.Atoi(b)
  if err != nil {
    return 0,  fmt.Errorf("can't parse b: %s, err: %v", b, err)
  }
  return x + y
}

そして、まだ混沌とした気分になっています（共感するのに役立ちます） catchが気に入らない場合は、それを使用する必要はありません。

さて...私はそれが最後の文であるという意味ではありませんが、それは議論に役立たないように感じます、非常に攻撃的なIMO。
それでも、このルートを使用した場合は、代わりにtry{}catch(error err){}を使用することもできます：stuck_out_tongue：

＃27519-＃id / catchエラーモデルも参照してください

誰もあなたに試してもらうつもりはありません。

ざらざらしていることを無視すると、それはデザインに対する批判を却下するためのかなり手に負えない方法だと思います。

申し訳ありませんが、glibは私の意図ではありませんでした。

私が言おうとしているのは、 tryは100％の解決策を意図したものではないということです。 tryでは適切に処理されないさまざまなエラー処理パラダイムがあります。 たとえば、callsiteに依存するコンテキストをエラーに追加する必要がある場合です。 これらのより複雑なケースを処理するために、いつでもif err != nil {の使用にフォールバックできます。

Xのさまざまなインスタンスについて、 tryがXを処理できないことは確かに有効な議論です。しかし、多くの場合、ケースXを処理することは、メカニズムをより複雑にすることを意味します。 ここにはトレードオフがあり、一方でXを処理しますが、他のすべてのメカニズムを複雑にします。 私たちが何をするかは、Xがどれほど一般的であるか、およびXを処理するためにどれだけ複雑になるかによって異なります。

つまり、「誰もあなたに試してもらうつもりはない」ということは、問題の例が90％ではなく10％にあると私が思うことを意味します。 その主張は確かに議論の余地があり、反論を聞いてうれしいです。 しかし、最終的にはどこかに線を引き、「ええ、 tryはそのケースを処理しません。古いスタイルのエラー処理を使用する必要があります。ごめんなさい」と言う必要があります。

問題は「この特定のエラー処理のケースを処理できない」ということではなく、「エラーをラップしないように勧める」ということです。 check-handleのアイデアでは、returnステートメントを作成する必要があったため、エラーラッピングを作成するのは非常に簡単でした。

この提案では、 deferの名前付きリターンを使用する必要がありますが、これは直感的ではなく、非常にハッキーなようです。

check-handleのアイデアでは、returnステートメントを作成する必要があったため、エラーラッピングを作成するのは非常に簡単でした。

これは真実ではありません。設計ドラフトでは、エラーを返すすべての関数には、エラーを返すだけのデフォルトのハンドラーがあります。

@Goodwineの欠点に基づいて、次のような単一のブリッジ関数がある場合、 HandleErrorfのような個別の関数は実際には必要ありません。

func handler(err *error, handle func(error) error) {
  // nil handle is treated as the identity
  if *err != nil && handle != nil {
    *err = handle(*err)
  }
}

あなたが好きなものを使用します

defer handler(&err, func(err error) error {
  if errors.Is(err, io.EOF) {
    return nil
  }
  return fmt.Errorf("oops: %w", err)
})

handler自体をtryのようなセミマジックビルトインにすることができます。

それが魔法の場合、最初の引数を暗黙的に取ることができます。 errorの戻り値に名前を付けない関数でも使用できるようにし、現在の提案の不幸な側面の1つをノックアウトし、それを少なくします。うるさくてエラーが発生しやすく、エラーが発生しやすくなります。 もちろん、これで前の例が大幅​​に減ることはありません。

defer handler(func(err error) error {
  if errors.Is(err, io.EOF) {
    return nil
  }
  return fmt.Errorf("oops: %w", err)
})

このように魔法の場合、 deferの引数以外の場所で使用すると、コンパイル時エラーになるはずです。 さらに一歩進んで暗黙的に延期することもできますが、 defer handler非常にうまく読み取れます。

deferを使用するため、nil以外のエラーが返されるたびに、 handle funcを呼び出すことができ、 tryがなくても、

defer handler(wrapErrWithPackageName)

一番上にfmt.Errorf("mypkg: %w", err)すべて。

これにより、古いcheck / handleの提案が多数提供されますが、ほとんどの場合、 errに明示的に名前を付ける必要がなくなり、自然に（そして明示的に）延期して機能します。 tryのように、それは（私が想像する）比較的単純なマクロであり、完全にフロントエンドに実装することができます。

これは真実ではありません。設計ドラフトでは、エラーを返すすべての関数には、エラーを返すだけのデフォルトのハンドラーがあります。

私の悪い、あなたは正しいです。

問題の例は90％ではなく10％にあると思います。 その主張は確かに議論の余地があり、反論を聞いてうれしいです。 しかし、最終的にはどこかに線を引き、「ええ、試してみてもそのケースは処理されません。古いスタイルのエラー処理を使用する必要があります。ごめんなさい」と言わなければなりません。

同意しました。私の意見では、この線は、折り返しではなく、EOFなどをチェックするときに描画する必要があります。 しかし、エラーにコンテキストが多ければ、これはもう問題にはなりません。

try()は、デバッグに役立つコンテキストでエラーを自動ラップできますか？ たとえば、 xerrorsがerrorsになった場合、エラーにはtry()が追加できるスタックトレースのようなものが必要です。 もしそうなら多分それで十分でしょう🤔

目標が（https://github.com/golang/proposal/blob/master/design/32437-try-builtin.mdを読む）の場合：

• ボイラープレートを削除する
• 最小限の言語変更
• 「最も一般的なシナリオ」をカバーする
• 言語にほとんど複雑さを加えない

私はそれに角度を付けて、そこにある数十億行のコードすべてに対して「小さなステップ」のコード移行を許可するという提案を受け入れます。

提案の代わりに：

func printSum(a, b string) error {
        defer fmt.HandleErrorf(&err, "sum %s %s: %v", a,b, err) 
        x := try(strconv.Atoi(a))
        y := try(strconv.Atoi(b))
        fmt.Println("result:", x + y)
        return nil
}

我々はできる：

func printSum(a, b string) error {
        var err ErrHandler{HandleFunc : twoStringsErr("printSum",a,b)} 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        return nil
}

私たちは何を得るでしょうか？
twoStringsErrは、printSum、またはエラーをキャプチャする方法を知っている一般的なハンドラー（この場合は2つの文字列パラメーター）にインライン化できます-したがって、多くの関数で同じ繰り返しfuncシグネチャが使用されている場合は、ハンドラーをそれぞれ書き直す必要はありません時間
同様に、ErrHandlerタイプを次のように拡張できます。

type ioErrHandler ErrHandler
func (i ErrHandler) Handle() ...{

}

また

type parseErrHandler ErrHandler
func (p parseErrHandler) Handle() ...{

}

また

type str2IntErrHandler ErrHandler
func (s str2IntErrHandler) Handle() ...{

}

そしてこれを私のコード全体で使用します：

func printSum(a, b string) error {
        var pErr str2IntErrHandler 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        return nil
}

したがって、実際に必要なのは、err.Errorがnilではないように設定されているときにトリガーを開発することです。
この方法を使用すると、次のこともできます。

func (s str2IntErrHandler) Handle() bool{
   **return false**
}

これは、呼び出し元の関数に、戻る代わりに続行するように指示します

また、同じ関数で異なるエラーハンドラーを使用します。

func printSum(a, b string) error {
        var pErr str2IntErrHandler 
        var oErr overflowError 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        totalAsByte,oErr := sumBytes(x,y)
        sunAsByte,oErr := subtractBytes(x,y)
        return nil
}

等

もう一度目標を超える

• ボイラープレートを排除する-完了
• 最小限の言語変更-完了
• 「最も一般的なシナリオ」をカバーする-提案されたIMO以上のもの
• 言語にほとんど複雑さを加えない-sone
  プラス-からのより簡単なコード移行

x, err := strconv.Atoi(a)

に

x, err.Error := strconv.Atoi(a)

そして実際には-読みやすさの向上（IMO、再び）

@guybrandあなたはこの定期的なテーマ（私が好きです）の最新の支持者です。

https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring-themesを参照してください

@guybrandそれはまったく別の提案のようです。 これを@griesemerの提案の議論に集中できるように、それを独自の問題として提出する必要があると思います。

@natefinchは同意します。 これは、読書用に最適化するのではなく、Goを書いている間のエクスペリエンスを改善することを目的としていると思います。 IDEマクロまたはスニペットは、これが言語の機能になることなく問題を解決できるのではないかと思います。

@Goodwine

エラーを有用なコンテキストでラップすることは良い習慣だとしましょうtry()はコンテキストを追加しないため、悪い習慣と見なされます。 これは、 try()が誰も使用したくない機能であり、ほとんど使用されないために存在しなかった可能性がある機能になることを意味します。

提案に記載されているように（そして例で示されているように）、 tryは基本的にコンテキストの追加を妨げるものではありません。 私はそれが提案されている方法、エラーにコンテキストを追加することはそれと完全に直交していると思います。 これは、提案のFAQで具体的に取り上げられています。

tryは、関数呼び出しからのさまざまなエラーに追加したいさまざまなコンテキストが多数ある場合に、単一の関数内にある場合は役に立たないことを認識しています。 ただし、エラーに関数全体のコンテキストを追加することだけが珍しいことではないため、 HandleErrorfの一般的な意味での使用範囲が広いと思います。

「まあ、気に入らないのなら、使わないで黙って」と言うのではなく（こういう読み方です）、多くの人が欠陥を考えていることに対処してみたほうがいいと思います。デザインで。

それがそれが読む方法であるならば、私は謝罪します。 私の言いたいことは、気に入らなければ存在しないふりをするべきだということではありません。 tryが役に立たない場合があることは明らかであり、そのような場合には使用すべきではありません。この提案では、KISSと一般的なユーティリティのバランスが取れていると思います。 その点で不明確だとは思いませんでした。

これまでの多くのフィードバックに感謝します。 これは非常に有益です。
これが、フィードバックをよりよく理解するための最初の要約での私の試みです。 私が見逃したり、誤って伝えたりした人には、事前に謝罪します。 私はそれの全体的な要点を正しく理解したことを願っています。

0）良い面として、 @ rasky 、 @ adg 、 @ eandre 、 @ dpinelaなどは、 tryが提供するコードの単純化に対して幸福を明示的に表現しました。

1）最も重要な懸念は、 tryが適切なエラー処理スタイルを促進せず、代わりに「迅速な終了」を促進することであるように思われます。 （@ agnivade 、@ peterbourgon 、@ politician、@ a8m 、@ eandre 、 @ prologic 、 @ kungfusheep 、@ cpuguy 、および他の人がこれについて懸念を表明しています。）

2）多くの人は、組み込みのアイデアや、それに付属する関数構文がreturnを隠すため、それを嫌います。 キーワードを使用する方が良いでしょう。 （@ sheerun 、@ Redundancy 、@ dolmen、@ komuw 、@ RobertGrantEllis 、@ elagergren -spideroak）。 tryも簡単に見落とされる可能性があります（@peterbourgon）。特に、任意にネストされている可能性のある式に表示される可能性があるためです。 @natefinchは、 tryによって、「1行に大量にダンプするのが簡単すぎる」ことを懸念しています。これは、Goでは通常避けようとしていることです。 また、 tryを強調するIDEサポートでは不十分な場合があります（@dominikh）。 tryは「自立」する必要があります。

3）一部の人にとって、明示的なifステートメントの現状は問題ではなく、彼らはそれに満足しています（@ bitfield 、@ marwan-at-work、@ natefinch）。 物事を行う方法は1つだけにすることをお勧めします（@gbbr）。 明示的なifステートメントは、暗黙的なreturn （ @ DavexPro 、 @ hmage 、 @ prologic 、@ natefinch）よりも優れています。
同じように、 @ mattnは、エラー結果がtryに「暗黙的にバインド」されることを懸念しています。つまり、接続はコードに明示的に表示されません。

4） tryを使用すると、コードのデバッグが難しくなります。 たとえば、デバッグステートメントを挿入できるようにするために、 try式をifステートメントに書き直す必要がある場合があります（ @ deanveloper 、 @ typeless 、 @ networkimprov 、その他）。

5）名前付きリターン（ @ buchanae 、@ adg）の使用についていくつかの懸念があります。

何人かの人々が提案を改善または修正するための提案を提供しました：

6）適切なエラー処理を促進するために、オプションのエラーハンドラー（@beoran）またはtry （@ unexge 、 @ a8m 、@ eandre 、@ gotwarlost）に提供されるフォーマット文字列のアイデアを採用した人もいます。

7） @pierrecは、 gofmtがtry式を適切にフォーマットして、より見やすくすることを提案しました。
または、 gofmtでifステートメントをフォーマットして、1行のエラーをチェックすることで既存のコードをよりコンパクトにすることもできます（@zeebo）。

8）@ marwan-at-workは、 try 、エラー処理をifステートメントからtry式に単純にシフトすると主張しています。 代わりに、実際に問題を解決したい場合、Goはエラー処理を真に暗黙的にすることで「所有」する必要があります。 目標は、（適切な）エラー処理をより簡単にし、開発者の生産性を高めることです（@cpuguy）。

9）最後に、 try $（@ beoran 、@ HiImJC 、@ dolmen）という名前が気に入らない人や、 ? （ @ twinsted1919 、@ leaxoy 、その他）などの記号を好む人もいます。 。

このフィードバックに関するいくつかのコメント（それに応じて番号が付けられています）：

0）正のフィードバックをありがとう！ :-)

1）この懸念についてもっと学ぶのは良いことです。 ifステートメントを使用してエラーをテストする現在のコーディングスタイルは、可能な限り明示的です。 個別に（ ifごとに）エラーに追加情報を追加するのは非常に簡単です。 多くの場合、関数で検出されたすべてのエラーを統一された方法で処理することは理にかなっています。これは、 deferで実行できます。これはすでに可能です。 言語で適切なエラー処理を行うためのすべてのツールがすでに用意されているという事実と、ハンドラー構造がdeferに直交していないという問題が原因で、エラーを増やすためだけに新しいメカニズムを省略しました。 。

2）もちろん、組み込みの代わりにキーワードまたは特別な構文を使用する可能性があります。 新しいキーワードには下位互換性はありません。 新しい演算子はそうかもしれませんが、さらに目立たないようです。 詳細な提案では、さまざまな長所と短所について詳しく説明しています。 しかし、おそらく私たちはこれを誤解しています。

3）この提案の理由は、エラー処理（特に関連するボイラープレートコード）がGoコミュニティによってGoの重要な問題（ジェネリックスの欠如の次に）として言及されたためです。 この提案は、定型的な懸念に直接対処します。 より複雑なケースは、すでに持っているものでより適切に処理されるため、最も基本的なケースを解決する以上のことはしません。 したがって、かなりの数の人々が現状に満足していますが、これが「ただ」であることをよく知っている、 tryなどのより合理化されたアプローチを好む（おそらく）同じくらい多くの人々の派遣団がありますシンタックスシュガー。

4）デバッグポイントは有効な懸念事項です。 エラーの検出とreturnの間にコードを追加する必要がある場合、 try式をifステートメントに書き直さなければならないのは煩わしいかもしれません。

5）名前付きの戻り値：詳細なドキュメントでは、これについて詳しく説明しています。 これがこの提案の主な関心事である場合、私たちは良い状況にあると思います。

6） tryへのオプションのハンドラー引数：詳細なドキュメントでは、これについても説明しています。 設計の反復に関するセクションを参照してください。

7） gofmtを使用して$ try式をフォーマットし、それらが余分に見えるようにすることは確かにオプションです。 ただし、式で使用すると、 tryの利点の一部が失われます。

8）エラーテスト（ try ）の観点からではなく、エラー処理（ handle ）の観点から問題を検討することを検討しました。 具体的には、エラーハンドラの概念のみを導入することを簡単に検討しました（昨年のGopherconで提示された元の設計ドラフトと同様）。 ハンドラーが宣言されている場合（そしてその場合のみ）、最後の値がerror型である複数値の割り当てでは、その値を割り当てにそのまま残すことができると考えられていました。 コンパイラーは、それがnilでないかどうかを暗黙的にチェックし、そうでない場合はハンドラーに分岐します。 これにより、明示的なエラー処理が完全になくなり、代わりにハンドラーを作成するように促されます。 これは完全に暗黙的であるため、極端なアプローチのように見えました。チェックが行われるという事実は見えません。

9）現時点では、名前を自転車で流さないことをお勧めします。 他のすべての懸念が解決したら、名前を微調整するのに適した時期です。

これは、懸念が有効ではないということではありません。上記の回答は、単に私たちの現在の考えを述べているだけです。 今後は、新しい懸念事項（またはこれらの懸念事項を裏付ける新しい証拠）についてコメントすることをお勧めします。すでに述べたことを言い換えても、それ以上の情報は得られません。

そして最後に、この問題についてコメントしているすべての人が詳細なドキュメントを読んだわけではないようです。 すでに言われたことを繰り返さないように、コメントする前にそうしてください。 ありがとう。

これは提案に対するコメントではなく、タイプミスの報告です。 完全な提案が公開されてから修正されなかったので、私はそれについて言及したいと思いました：

func try(t1 T1, t1 T2, … tn Tn, te error) (T1, T2, … Tn)

する必要があります：

func try(t1 T1, t2 T2, … tn Tn, te error) (T1, T2, … Tn)

ほとんどのエラーチェックが本当に反復的であるかどうか、またはほとんどの場合、同じ関数内の複数のチェックが異なるコンテキスト情報を追加するかどうかを判断するために、エラーチェックステートメントの公開されているGoコードを分析する価値がありますか？ この提案は前者の場合には非常に理にかなっていますが、後者の場合には役立ちません。 後者の場合、人々はif err != nilを使い続けるか、コンテキストの追加をあきらめ、 try()を使用して、IMOが有害となる関数ごとに一般的なエラーコンテキストを追加することになります。 今後のエラー値機能により、エラーをより多くの情報でラップすることが多くなると思います。 おそらく私は提案を誤解しましたが、AFAIUは、単一の関数からのすべてのエラーを正確に1つの方法でラップする必要がある場合にのみボイラープレートを減らすのに役立ち、関数が別の方法でラップする必要がある5つのエラーを処理する場合は役に立ちません。 このようなケースが実際にどれほど一般的であるかはわかりませんが（私のプロジェクトのほとんどでかなり一般的です）、さまざまなエラーをラップすることが理にかなっている場合でも、 try()が関数ごとに一般的なラッパーを使用するように促す可能性があるのではないかと心配しています別の方法で。

小さなサンプルセットのデータに裏打ちされた簡単なコメント：

通常Goでのエラー処理に関連するステートメントの場合、ボイラープレートを排除するために特別に設計された、tryと呼ばれる新しい組み込み関数を提案します。

これがこの提案によって解決される主要な問題である場合、この「ボイラープレート」は、合計で約60k SLOCの数十の公開されているオープンソースプロジェクト全体で、私のコードの約1.4％しか占めていないことがわかります。

他の誰かが同様の統計を持っているかどうか知りたいですか？

Go自体のようなはるかに大きなコードベースでは、合計で約160万SLOCになります。これは、 if err != nilのような行を持つコードベースの約0.5％に相当します。

これは、Go 2で解決するのに本当に最も影響力のある問題ですか？

皆さんのアイデアをじっくりと見ていただき、明示的に考えを提供してくださった@griesemerに感謝します。 その過程でコミュニティが耳を傾けているという認識に本当に役立つと思います。

1. @pierrecは、gofmtがtry式を適切にフォーマットして、より見やすくすることを提案しました。
   または、1行のエラーをチェックするifステートメント（@zeebo）をgofmtでフォーマットできるようにすることで、既存のコードをよりコンパクトにすることもできます。

1. gofmtを使用して$ try式をフォーマットし、それらが余分に見えるようにすることは確かにオプションです。 ただし、式で使用すると、 tryの利点の一部が失われます。

これらは、 try gofmtを要求することについての貴重な考えですが、特にgofmtについて、 ifステートメントのチェックを許可することについて何か考えがあるかどうか興味があります。エラーは1行です。 提案はtryのフォーマットでまとめられましたが、それは完全に直交するものだと思います。 ありがとう。

@griesemerは、すべてのコメントを通過し、すべてではないにしてもほとんどのフィードバックに答える素晴らしい作業に感謝します🎉

フィードバックで取り上げられなかったことの1つは、Go構文を更新するのではなく、Go言語のツール/検査部分を使用してエラー処理エクスペリエンスを向上させるというアイデアでした。

たとえば、新しいLSP（ gopls ）がリリースされたので、関数のシグネチャを分析し、開発者のエラー処理ボイラープレートを適切にラッピングして検証するのに最適な場所のようです。

@griesemerこれはよく考えられていないことは確かですが、私はあなたの提案をここで快適なものに近づけようとしました： https ：//www.reddit.com/r/golang/comments/bwvyhe

@zeebo 1行でgofmt形式のif err != nil { return ...., err }を作成するのは簡単です。 おそらく、この特定の種類のifパターンのみであり、すべての「短い」 ifステートメントではないでしょうか。

同じ行に沿って、 tryはビジネスロジックと同じ行にあるため、表示されないという懸念がありました。 これらすべてのオプションがあります。

現在のスタイル：

a, b, c, ... err := BusinessLogic(...)
if err != nil {
   return ..., err
}

1行if ：

a, b, c, ... err := BusinessLogic(...)
if err != nil { return ..., err }

別の行にtry （！）：

a, b, c, ... err := BusinessLogic(...)
try(err)

提案されたtry ：

a, b, c := try(BusinessLogic(...))

最初と最後の行は（私には）最も明確に見えます。特に、 tryをそれが何であるかを認識するために使用された場合はなおさらです。 最後の行では、エラーが明示的にチェックされますが、（通常は）メインアクションではないため、バックグラウンドでもう少しエラーが発生します。

@ marwan-at-workツールがあなたのために何をするのかあなたが何を提案しているのかわかりません。 どういうわけかエラー処理を隠すことを提案しますか？

@dpinela

@guybrandそれはまったく別の提案のようです。 これを@griesemerの提案の議論に集中できるように、それを独自の問題として提出する必要があると思います。

IMO私の提案は、構文のみが異なります。つまり、次のようになります。

• 目標は内容と優先順位が似ています。
• 各エラーを独自の行内にキャプチャし、それに応じて（nilでない場合）ハンドラー関数を通過しながら関数を終了するという考え方も同様です（疑似asm-その「jnz」と「call」）。
• これは、関数本体の行数（延期なし）とフローがまったく同じように見えることを意味します（したがって、ASTもおそらく同じになるでしょう）

したがって、主な違いは、元の関数呼び出しをtry（func（））でラップするかどうかです。これは、呼び出しをjnzするために常に最後の変数を分析するか、実際の戻り値を使用してそれを行います。

見た目は違いますが、実際には概念が非常に似ています。
一方、通常の試みを行う場合は、多くのC言語のような言語でキャッチします。これは、実装や読みやすさなどが大きく異なります。

しかし、私は提案を書くことを真剣に考えています。アイデアに感謝します。

@griesemer

ツールがあなたのために何をするのか、あなたが何を提案しているのかわかりません。 どういうわけかエラー処理を隠すことを提案しますか？

まったく逆ですgoplsは、オプションでエラー処理の定型文を作成できることをお勧めします。

あなたが最後のコメントで述べたように：

この提案の理由は、エラー処理（特に関連するボイラープレートコード）がGoコミュニティによってGoの重要な問題として言及されたためです（ジェネリックスの欠如の次に）

したがって、問題の核心は、プログラマーが多くの定型コードを書くことになってしまうことです。 したがって、問題は読むことではなく、書くことです。 したがって、私の提案は次のとおりです。関数の署名を分析し、適切なエラー処理句を配置することにより、コンピューター（tooling / gopls）にプログラマーのための書き込みを行わせます。

例えば：

// user begins to write this function: 
func openFile(path string) ([]byte, error) {
  file, err := os.Open(path)
  defer file.Close()
  bts, err := ioutil.ReadAll(file)
  return bts, nil
}

次に、ユーザーはおそらくファイルを保存するだけでツールをトリガーし（gofmt / goimportsが通常機能する方法と同様）、 goplsはこの関数を調べ、その戻り署名を分析し、コードを次のように拡張します。

// user has triggered the tool (by saving the file, or code action)
func openFile(path string) ([]byte, error) {
  file, err := os.Open(path)
  if err != nil {
    return nil, fmt.Errorf("openFile: %w", err)
  }
  defer file.Close()
  bts, err := ioutil.ReadAll(file)
  if err != nil {
    return nil, fmt.Errorf("openFile: %w", err)
  }
  return bts, nil
}

このようにして、両方の長所を活用できます。現在のエラー処理システムの可読性/明示性が得られ、プログラマーはエラー処理の定型文を作成しませんでした。 さらに良いことに、ユーザーは後でエラー処理ブロックを変更して別の動作を行うことができます。 goplsはブロックが存在することを理解でき、ブロックは変更されません。

ツールは、早期に戻るのではなく、関数の後半でerrを処理するつもりだったことをどのように知るのでしょうか。 まれではありますが、それでも私が書いたコードです。

これまでに提起されたことがあることをお詫び申し上げますが、言及が見つかりませんでした。

try(DoSomething())は私にはよく読まれ、理にかなっています。コードは何かを行おうとしています。 try(err) 、OTOHは、意味的に言えば、少し気分が悪くなります。どのようにしてエラーを試行しますか？ 私の考えでは、エラーを_テスト_または_チェック_することはできますが、_試行_することは正しくないようです。

一貫性の理由から、 try(err)を許可することが重要であることを私は理解しています。 try(DoSomething())が機能した場合は奇妙だと思いますが、 err := DoSomething(); try(err)は機能しませんでした。 それでも、 try(err)はページ上で少しぎこちなく見えます。 これほど簡単に奇妙に見えるようにすることができる他の組み込み関数は考えられません。

具体的な提案はありませんが、それでもこの観察をしたいと思いました。

@griesemerありがとう。 確かに、提案はreturnのみを対象としたものでしたが、1つのステートメントを1行にするのは良いことだと思います。 たとえば、テストでは、テストライブラリを変更せずに、次のことができます。

if err != nil { t.Fatal(err) }

最初と最後の行は（私には）最も明確に見えます。特に、tryをそれが何であるかを認識するために使用された場合はなおさらです。 最後の行では、エラーが明示的にチェックされますが、（通常は）メインアクションではないため、バックグラウンドでもう少しエラーが発生します。

最後の行では、コストの一部が隠されています。 コミュニティが声に出して言っているエラーに注釈を付けたい場合は、ベストプラクティスが望ましいため、推奨する必要があります。関数のシグネチャを変更して引数に名前を付け、単一のdeferが適用されることを期待する必要があります。関数本体のすべての出口、それ以外の場合、 tryには値がありません。 おそらくその容易さのために否定的ですらあります。

まだ言われていないと思うことを追加する必要はもうありません。

デザインドキュメントからこの質問に答える方法がわかりませんでした。 このコードは何をしますか：

func foo() (err error) {
    src := try(getReader())
    if src != nil {
        n, err := src.Read(nil)
        if err == io.EOF {
            return nil
        }
        try(err)
        println(n)
    }
    return nil
}

私の理解はそれが脱糖するだろうということです

func foo() (err error) {
    tsrc, te := getReader()
    if err != nil {
        err = te
        return
    }
    src := tsrc

    if src != nil {
        n, err := src.Read(nil)
        if err == io.EOF {
            return nil
        }

        terr := err
        if terr != nil {
            err = terr
            return
        }

        println(n)
    }
    return nil
}

errがネイキッドリターン中にシャドウされるため、コンパイルに失敗します。 これはコンパイルされませんか？ もしそうなら、それは非常に微妙な失敗であり、起こりそうにないようです。 そうでない場合は、砂糖よりも多くのことが起こっています。

@ marwan-at-work

あなたが最後のコメントで述べたように：

この提案の理由は、エラー処理（特に関連するボイラープレートコード）がGoコミュニティによってGoの重要な問題として言及されたためです（ジェネリックスの欠如の次に）

したがって、問題の核心は、プログラマーが多くの定型コードを書くことになってしまうことです。 したがって、問題は読むことではなく、書くことです。

実際には逆だと思います。私にとって、現在のエラー処理ボイラープレートの最大の煩わしさは、入力する必要がないことではなく、関数のハッピーパスを画面全体に垂直に分散させて理解するのを難しくしていることです。一目。 この効果は、I / Oが多いコードで特に顕著であり、通常、2つの操作ごとにボイラープレートのブロックがあります。 CopyFileの単純なバージョンでも、実際には5つのステップ（オープンソース、クローズソースの延期、オープン宛先、コピーソース->宛先、クローズ宛先）しか実行しませんが、最大20行かかります。

現在の構文のもう1つの問題は、前述したように、それぞれがエラーを返す可能性のある一連の操作がある場合、現在の構文では、必要な場合でも、すべての中間結果に名前を付ける必要があることです。匿名のままにしておきます。 これが発生すると、あまり有益ではありませんが、これらの名前を解析するために脳のサイクルを費やす必要があるため、読みやすさも損なわれます。

別の行のtryが好きです。
そして、 handler funcを個別に指定できることを願っています。

func try(error, optional func(error)error)

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    try(err)

    handle := func(err error) error {
        tx.Rollback()
        return err
    }

    var res int64
    _, err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    try(err, handle)

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    try(err, handle)

    return tx.Commit()
}

@zeebo ：私が挙げた例は1：1の翻訳です。 最初の（従来のif ）はエラーを処理しなかったため、他のエラーも処理しませんでした。 最初にエラーを処理し、これが関数でエラーがチェックされる唯一の場所である場合、最初の例（ ifを使用）がコードの記述の適切な選択である可能性があります。 複数のエラーチェックがあり、それらすべてが同じエラー処理（ラッピング）を使用している場合、たとえば、それらはすべて現在の関数に関する情報を追加するため、 deferステートメントを使用してすべてのエラーを1か所で処理できます。 オプションで、 ifをtryに書き換えることができます（またはそのままにしておきます）。 チェックするエラーが複数あり、それらすべてがエラーを異なる方法で処理する場合（これは、関数の懸念が広すぎて分割する必要がある可能性があることを示している可能性があります）、 ifを使用するのが行く方法。 はい、同じことを行う方法は複数あります。正しい選択は、コードと個人の好みによって異なります。 Goでは「1つのことを行う1つの方法」を目指して努力していますが、特に一般的な構成では、もちろんこれはすでに当てはまりません。 たとえば、 if - else - ifシーケンスが長くなりすぎる場合は、 switchの方が適切な場合があります。 変数宣言var x intは、 x := 0などよりも意図を表す場合があります（ただし、誰もがこれに満足しているわけではありません）。

「書き換え」に関する質問について：いいえ、コンパイルエラーは発生しません。 書き換えは内部で行われ（コードパターンが示唆するよりも効率的である可能性があります）、コンパイラがシャドウリターンについて文句を言う必要はないことに注意してください。 あなたの例では、ネストされたスコープでローカルのerr変数を宣言しました。 もちろん、 tryは、結果のerr変数に直接アクセスできます。 書き直しは、裏でこのように見えるかもしれません。

[編集] PS：より良い答えは次のようになります： tryは裸のリターンではありません（書き直しはそのように見えますが）。 結局のところ、 nilない場合に返されるエラーを含む（またはそうである）引数を明示的にtryに与えます。 ネイキッドリターンのシャドウエラーは、ソースのエラーです（ソースの基になる変換ではありません。コンパイラはエラーを必要としません。

包括的な関数の最終的な戻り型が型エラーではない場合、パニックになる可能性がありますか？

ビルトインをより用途の広いものにします（＃32219の私の懸念を満たすなど）

@pjebsこれは検討され、反対されました。 詳細な設計ドキュメント（このテーマに関する問題を明示的に参照しています）をお読みください。

また、try（）はreturnステートメントとして機能しますが、式として扱われることを指摘したいと思います。 はい、tryは組み込みマクロですが、ほとんどのユーザーは関数型プログラミングのようにこれを使用すると思います。

func doSomething() (error, error, error, error, error) {
   ...
}

try(try(try(try(try(doSomething)))))

設計では、エラーを返す代わりにpanicを使用して探索したとしています。

私は微妙な違いを強調しています：

包括的な関数がタイプerrorの最終的な戻り型を持たなければならないという制限を取り除くことを除いて、現在の提案が述べていることを正確に実行してください。

最終的な返品タイプがerrorでない場合=>パニック
try for packageレベルの変数宣言を使用する場合=>パニック（ MustXXX( )規則の必要性を排除します）

単体テストの場合、言語を少し変更します。

@mattn 、かなりの数の人がそのようなコードを書くのではないかと私は強く疑っています。

@pjebs 、そのセマンティクス（現在の関数にエラー結果がない場合はパニック）は、設計ドキュメントがhttps://github.com/golang/proposal/blob/master/design/32437-try-builtinで説明しているものとまったく同じです。 md＃discussion。

さらに、エラー結果のある関数内だけでなく、tryを有用なものにするために、tryのセマンティクスはコンテキストによって異なります。tryがパッケージレベルで使用された場合、またはエラー結果のない関数内で呼び出された場合、エラーが発生するとパニックになります。 （余談ですが、そのプロパティのために、ビルトインはその提案で試すのではなく、必須と呼ばれていました。）このコンテキスト依存の方法で試行（または必須）することは自然であり、非常に便利であるように見えました。多くのユーザー定義のmustヘルパー関数は、パッケージレベルの変数初期化式で現在使用されています。 また、テストパッケージを介して単体テストでtryを使用する可能性も開かれます。

ただし、tryのコンテキスト依存性は問題があると見なされていました。たとえば、エラー結果がシグニチャに追加または削除された場合、try呼び出しを含む関数の動作がサイレントに変更される可能性があります（パニックになる可能性からパニックにならない、またはその逆）。 これは危険すぎる物件のようでした。 明らかな解決策は、tryの機能を2つの別々の関数であるmustとtryに分割することでした（問題＃31442で提案されているものと非常に似ています）。 しかし、それには2つの新しい組み込み関数が必要であり、より優れたエラー処理サポートの差し迫った必要性に直接接続してみてください。

@pjebsこれは、以前の提案で_正確に_検討したことです（詳細なドキュメント、設計の反復に関するセクション、第4段落を参照）。

さらに、エラー結果のある関数内だけでなく、tryを有用なものにするために、tryのセマンティクスはコンテキストによって異なります。tryがパッケージレベルで使用された場合、またはエラー結果のない関数内で呼び出された場合、エラーが発生するとパニックになります。 （余談ですが、そのプロパティのために、ビルトインはその提案で試すのではなく、呼び出される必要があります。）

（Go Teamの内部）コンセンサスは、 tryがコンテキストに依存し、そのように異なる動作をすることは混乱を招くだろうというものでした。 たとえば、エラー結果を関数に追加する（または削除する）と、関数の動作がパニックからパニックにならないように（またはその逆に）サイレントに変更される可能性があります。

@griesemer書き直しについて説明してくれてありがとう。 コンパイルしてよかったです。

例はエラーに注釈を付けなかった翻訳であったことを理解しています。 tryを使用すると、一般的な状況でエラーの適切な注釈を付けることが難しくなり、エラーの注釈はコミュニティにとって非常に重要であると主張しようとしました。 これまでのコメントの大部分は、 tryにより良いアノテーションサポートを追加する方法を模索してきました。

エラーを別の方法で処理する必要があることについては、関数の懸念が広すぎることの兆候であることに同意しません。 コメントから主張された実際のコードのいくつかの例を翻訳し、元のコメントの下部にあるドロップダウンに配置しました。例はhttps://github.com/golang/go/issues/32437#issuecommentにあります- 499007288私は一般的なケースをよく示していると思います：

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil { return nil, errors.WithMessage(err, "load config dir") }

    b := bytes.NewBuffer(nil)
    err = templates.ExecuteTemplate(b, "main", c)
    if err != nil { return nil, errors.WithMessage(err, "execute main template") }

    buf, err := format.Source(b.Bytes())
    if err != nil { return nil, errors.WithMessage(err, "format main template") }

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    err = ioutil.WriteFile(target, buf, 0644)
    if err != nil { return nil, errors.WithMessagef(err, "write file %s", target) }
    // ...
}

この関数の目的は、一部のデータに対してテンプレートを実行してファイルにすることです。 私はそれを分割する必要があるとは思わない、そしてそれらのエラーのすべてがそれらが延期から作成された線をちょうど得たならばそれは残念だろう。 これは開発者にとっては問題ないかもしれませんが、ユーザーにとってはあまり役に立ちません。

defer wrap(&err, "message: %v", err)のバグがいかに微妙で、経験豊富なGoプログラマーでさえもそれらがどのようにつまずいたかということも少しシグナルだと思います。

私の議論を要約すると、式ベースのエラーチェックよりもエラー注釈の方が重要だと思います。ステートメントベースのエラーチェックを3行ではなく1行にすることで、かなりのノイズリダクションを得ることができます。 ありがとう。

@griesemer申し訳ありませんが、パニックについて説明している別のセクションを読みましたが、危険についての説明は見当たりませんでした。

@zeeboこの例をありがとう。 この場合、 ifステートメントを使用するのが正確に正しい選択のようです。 ただし、要点を言えば、ifをワンライナーにフォーマットすると、これが少し合理化される可能性があります。

tryの2番目の引数としてハンドラーのアイデアをもう一度取り上げたいと思いますが、ハンドラー引数は_必須_ですが、nil可能です。 これにより、エラーの処理が例外ではなくデフォルトになります。 本当にエラーを変更せずに渡したい場合は、ハンドラーにnil値を指定するだけで、 tryは元の提案と同じように動作しますが、nil引数は視覚的な手がかりとして機能します。エラーは処理されていません。 コードレビュー中にキャッチしやすくなります。

file := try(os.Open("my_file.txt"), nil)

ハンドラーが提供されているがnilの場合はどうなりますか？ パニックを試すか、エラーハンドラーがないものとして扱う必要がありますか？

上記のように、 tryは元の提案に従って動作します。 エラーハンドラがないというようなことはなく、ゼロのハンドラだけです。

ハンドラーがnil以外のエラーで呼び出され、nilの結果を返した場合はどうなりますか？ これは、エラーが「キャンセル」されたことを意味しますか？ または、囲んでいる関数はnilエラーで戻る必要がありますか？

囲み関数はnilエラーで返されると思います。 tryが、nil以外のエラー値を受け取った後でも実行を継続できる場合は、非常に混乱する可能性があります。 これにより、ハンドラーは状況によってはエラーを「処理」できるようになります。 この動作は、たとえば「getまたはcreate」スタイルの関数で役立つ可能性があります。

func getOrCreateObject(obj *object) error {
    defaultObjectHandler := func(err error) error {
        if err == ObjectDoesNotExistErr {
            *obj = object{}
            return nil
        }
        return fmt.Errorf("getting or creating object: %v", err)
    }

    *obj = try(db.getObject(), defaultObjectHandler)
}

オプションのエラーハンドラーを許可すると、プログラマーが適切なエラー処理を完全に無視するようになるかどうかも明確ではありませんでした。 また、どこでも適切なエラー処理を行うのは簡単ですが、試行の1回の発生を見逃します。 などなど。

これらの懸念は両方とも、ハンドラーを必須のゼロ化可能な引数にすることで軽減されると思います。 プログラマーは、エラーを処理しないという意識的で明確な決定を下す必要があります。

ボーナスとして、エラーハンドラーを要求すると、短くネストされたtryが短くなるため、それらを思いとどまらせることもできると思います。 これをマイナス面と見る人もいるかもしれませんが、それはメリットだと思います。

@velovix私はこのアイデアが大好きですが、なぜエラーハンドラーが必要なのですか？ デフォルトでnilにすることはできませんか？ なぜ「視覚的な手がかり」が必要なのですか？

@griesemer @velovixのアイデアが採用されたが、 builtinに、エラーをパニックに変換する事前定義された関数が含まれていて、包括的な関数にエラーの戻り値があるという要件を削除した場合はどうなりますか？

包括的な関数がエラーを返さない場合、エラーハンドラなしtryを使用すると、コンパイル時エラーが発生します。

エラーハンドラを使用して、名前付きの返されたエラーを変更する上部のdeferの代わりに、エラーの場所でさまざまなライブラリなどを使用して、すぐに返されるエラーをラップすることもできます。

@pjebs

なぜエラーハンドラが必要なのですか？ デフォルトではnilにすることはできませんか？ なぜ「視覚的な手がかり」が必要なのですか？

これは、

1. tryの提案は、現在のところ、そうすることはそれほど単純ではないため、人々がエラーにコンテキストを提供することを思いとどまらせる可能性があります。

そもそもハンドラーがあるとコンテキストの提供が簡単になり、ハンドラーを必須の引数にすることでメッセージが送信されます。一般的な推奨ケースは、単にスタックに渡すのではなく、何らかの方法でエラーを処理またはコンテキスト化することです。 これは、Goコミュニティからの一般的な推奨事項と一致しています。

1. 元の提案文書からの懸念。 私は最初のコメントでそれを引用しました：

オプションのエラーハンドラーを許可すると、プログラマーが適切なエラー処理を完全に無視するようになるかどうかも明確ではありませんでした。 また、どこでも適切なエラー処理を行うのは簡単ですが、試行の1回の発生を見逃します。 などなど。

明示的なnilを渡す必要があると、エラーを適切に処理することを忘れにくくなります。 引数を省略して暗黙的に処理するのではなく、エラーを処理しないことを明示的に決定する必要があります。

https://github.com/golang/go/issues/32437#issuecomment-498497603で簡単に言及されている条件付きリターンについてさらに考えます。
そうみたいです
return if f, err := os.Open("/my/file/path"); err != nil
Goの既存のifの外観により準拠します。

return ifステートメントのルールを追加すると
最後の条件式（ err != nilなど）が存在しない場合、return ifステートメントの宣言の最後の変数は、タイプerrorです。次に、最後の変数の値が、暗黙の条件としてnilと自動的に比較されます。

次に、 return ifステートメントは次のように省略できます。
return if f, err := os.Open("my/file/path")

これは、 tryが提供する信号対雑音比に非常に近いものです。
return ifをtryに変更すると、次のようになります。
try f, err := os.Open("my/file/path")
これも、少なくとも構文的には、このスレッドで提案されている他のtryのバリエーションと同様になります。
個人的には、この場合、関数の出口点が非常に明示的になるため、 tryよりもreturn ifの方が好きです。 たとえば、デバッグするとき、大きな関数のすべての出口点を識別するために、エディター内でキーワードreturnを強調表示することがよくあります。

残念ながら、デバッグログを挿入するという不便さについても十分に役立っていないようです。
return ifのbodyブロックも許可しない限り、次のようになります。
オリジナル：

        return if f, err := os.Open("my/path") 

デバッグ時：

-       return if f, err := os.Open("my/path") 
+       return if f, err := os.Open("my/path") {
+               fmt.Printf("DEBUG: os.Open: %s\n", err)
+       }

return ifのボディブロックの意味は明らかだと思います。 deferの前に実行され、戻ります。

そうは言っても、Goの既存のエラー処理アプローチに不満はありません。
新しいエラー処理の追加がGoの現在の良さにどのように影響するかについてもっと心配しています。

@velovix 2番目の引数として明示的なハンドラー関数を使用するtryのアイデアが非常に気に入りました。 しかし、設計ドキュメントに記載されているように、明確な答えがない質問が多すぎました。 あなたはそれらのいくつかにあなたにとって合理的と思われる方法で答えました。 正解はまったく別のものだと他の誰かが考えている可能性が非常に高いです（そしてそれはGoチーム内での私たちの経験でした）。 たとえば、ハンドラー引数は常に提供する必要があるが、エラーの処理を気にしないことを明示するためにnilにすることができると述べています。 関数値（ nilリテラルではない）を提供し、その関数値（変数に格納されている）がたまたまnilの場合はどうなりますか？ 明示的なnil値と同様に、処理は必要ありません。 しかし、これはコードのバグであると主張する人もいるかもしれません。 または、nil値のハンドラー引数を許可することもできますが、関数がエラーを処理する場合とそうでない場合があります。ハンドラーが常に存在するように見えるため、コードからは必ずしも明らかではありません。 。 もう1つの引数は、関数がエラーを処理することが非常に明確になるため、エラーハンドラーのトップレベルの宣言を行う方がよいというものでした。 したがって、 defer 。 おそらくもっとあります。

この懸念についてもっと学ぶのは良いことです。 エラーをテストするためにifステートメントを使用する現在のコーディングスタイルは、可能な限り明示的です。 エラーに個別に（ifごとに）追加情報を追加するのは非常に簡単です。 多くの場合、関数で検出されたすべてのエラーを均一な方法で処理することは理にかなっています。これは、延期することで実行できます。これは、すでに可能です。 言語で適切なエラー処理を行うためのすべてのツールがすでに用意されているという事実と、ハンドラー構造が延期に直交していないという問題が原因で、エラーを増やすためだけの新しいメカニズムを省略しました。

@ griesemer -IIUC、あなたは、callsiteに依存するエラーコンテキストの場合、現在のifステートメントで問題ないと言っています。 一方、この新しいtry関数は、1か所で複数のエラーを処理する場合に役立ちます。

懸念されたのは、 if err != nil { return err}を実行するだけで問題ない場合もありますが、通常は、戻る前にエラーを装飾することをお勧めします。 そして、この提案は前者に対処しているようであり、後者にはあまり効果がありません。 これは本質的に、人々がイージーリターンパターンを使用することを奨励されることを意味します。

@agnivade正解です。この提案は、エラーの装飾にはまったく役立ちません（ただし、 deferの使用をお勧めします）。 その理由の1つは、このための言語メカニズムがすでに存在していることです。 特に個々のエラーに基づいてエラー装飾が必要になるとすぐに、装飾コードのソーステキストの量が増えるため、 ifの負担が軽減されます。 これは、装飾が不要な場合、または装飾が常に同じである場合で、ボイラープレートが目に見える妨害になり、重要なコードを損なう場合です。

人々はすでに簡単なリターンパターンを使用することを奨励されています、 tryまたはtryなし、書くことはほんの少しです。 考えてみると、_エラー装飾を促進する唯一の方法は、それを必須にすることです_。どの言語サポートが利用可能であっても、エラーの装飾にはより多くの作業が必要になるためです。

取引を甘くする1つの方法は、 try （または類似のショートカット表記）のようなものだけを許可することです。明示的な（おそらく空の）ハンドラーがどこかに提供されている場合（元のドラフトデザインにはそのようなものがなかったことに注意してください）要件のいずれか）。

ここまで行きたいかどうかわかりません。 ライブラリの内部など、完全に細かいコードの多くは、どこでもエラーを装飾する必要がないことを言い換えさせてください。 たとえば、エラーを伝播して、APIエントリポイントを離れる直前に装飾するのは問題ありません。 （実際、それらをどこにでも飾ると、装飾が過剰なエラーが発生するだけで、実際の原因が隠されているため、重要なエラーを見つけるのが難しくなります。過度に冗長なログ記録と同様に、実際に何が起こっているのかを確認するのが難しくなります）。

キャッチ関数を追加することもできると思います。これは素晴らしいペアになるので、次のようにします。

func a() int {
  x := randInt()
  // let's assume that this is what recruiters should "fix" for us
  // or this happens in 3rd-party package.
  if x % 1337 != 0 {
    panic("not l33t enough")
  }
  return x
}

func b() error {
  // if a() panics, then x = 0, err = error{"not l33t enough"}
  x, err := catch(a())
  if err != nil {
    return err
  }
  sendSomewhereElse(x)
  return nil
}

// which could be simplified even further

func c() error {
  x := try(catch(a()))
  sendSomewhereElse(x)
  return nil
}

この例では、 catch()はrecover()パニックになり、 return ..., panicValueなります。
もちろん、関数があり、エラーも返すという明らかなコーナーケースがあります。 この場合、エラー値をパススルーするだけで便利だと思います。

したがって、基本的には、catch（）を使用して、実際にパニックを回復し、エラーに変えることができます。
これは私には非常に面白いように見えます。なぜなら、Goには実際には例外がないからですが、この場合、かなりきちんとしたtry（）-catch（）パターンがあり、Java（ catch(Throwable)メインのthrows LiterallyAnything ）。 通常のエラーのように、誰かのパニックを簡単に処理できます。 私は現在、現在のプロジェクトでGoに約6mln以上のLoCを持っています。これにより、少なくとも私にとっては物事が単純化されると思います。

@griesemerディスカッションの要約をありがとう。

そこに1つのポイントが欠けていることに気づきました。ジェネリックができるまでこの機能を待つべきだと主張する人もいます。これにより、この問題をよりエレガントな方法で解決できるようになることを願っています。

さらに、 @ velovixの提案も気に入っています。これにより、仕様に記載されているいくつかの質問が発生することはありがたいですが、 @ velovixがすでに行ったように、これらは合理的な方法で簡単に答えられると思います。

例えば：

• 関数値（nilリテラルではない）を提供し、その関数値（変数に格納されている）がたまたまnilである場合はどうなりますか？ =>エラー、期間を処理しないでください。 これは、エラー処理がコンテキストに依存し、エラー処理が必要かどうかに応じてハンドラ変数が設定される場合に役立ちます。 これはバグではなく、機能です。 :)

• もう1つの引数は、関数がエラーを処理することが非常に明確になるため、エラーハンドラーのトップレベルの宣言を行う方がよいというものでした。 =>したがって、関数の上部にあるエラーハンドラーを名前付きクロージャ関数として定義し、それを使用します。これにより、エラーを処理する必要があることも非常に明確になります。 これは深刻な問題ではなく、スタイル要件です。

他にどのような懸念がありましたか？ 私はそれらすべてが合理的な方法で同様に答えられることができるとかなり確信しています。

最後に、あなたが言うように、「取引を甘くする1つの方法は、明示的な（おそらく空の）ハンドラーがどこかに提供されている場合にのみ、try（または類似のショートカット表記）のようなものを許可することです」。 この提案を進める場合は、適切な「暗黙的よりも明示的」なエラー処理を促進するために、実際に「ここまで」とるべきだと思います。

@griesemer

関数値（nilリテラルではない）を提供し、その関数値（変数に格納されている）がたまたまnilである場合はどうなりますか？ 明示的なnil値と同様に、処理は必要ありません。 しかし、これはコードのバグであると主張する人もいるかもしれません。

理論的には、これは潜在的な落とし穴のように見えますが、ハンドラーが誤ってゼロになるという合理的な状況を概念化するのに苦労しています。 ハンドラーは、最も一般的には、他の場所で定義されたユーティリティ関数から、または関数自体で定義されたクロージャーとして取得されると思います。 これらのどちらも、予期せずにゼロになる可能性はありません。 理論的には、ハンドラー関数が他の関数への引数として渡されるシナリオが考えられますが、私の目には、それはかなり遠いもののように見えます。 おそらく、私が気付いていないこのようなパターンがあるでしょう。

もう1つの引数は、関数がエラーを処理することが非常に明確になるため、エラーハンドラーのトップレベルの宣言を行う方がよいというものでした。 したがって、 defer 。

@beoranが述べたように、ハンドラーを関数の上部近くのクロージャーとして定義すると、スタイルが非常に似たものになります。これが、人々がハンドラーを最も一般的に使用することを個人的に期待する方法です。 エラーを処理するすべての関数がdeferを使用するという事実によって得られる明快さには感謝しますが、関数が関数の途中でエラー処理戦略をピボットする必要がある場合は、不明確になる可能性があります。 次に、2つのdeferを確認し、読者はそれらが互いにどのように相互作用するかについて推論する必要があります。 これは、ハンドラーの議論がより明確で人間工学的であると私が信じる状況であり、これは_比較的_一般的なシナリオになると思います。

角かっこなしで動作させることは可能ですか？

つまり、次のようなものです。
a := try func(some)

@ Cyber​​ax-すでに上で述べたように、投稿する前にデザインドキュメントを注意深く読むことが非常に重要です。 これはトラフィックの多い問題であるため、多くの人が登録しています。

このドキュメントでは、演算子と関数について詳しく説明しています。

私はこれが8月のバージョンよりもずっと好きです。

returnキーワードなしの返品とは完全に反対ではない、否定的なフィードバックの多くは、2つのポイントに要約できると思います。

1. 人々は、ほとんどの場合に必要になる名前付きの結果パラメータを好みません
2. エラーに詳細なコンテキストを追加することはお勧めしません

たとえば、次を参照してください。

• https://github.com/golang/go/issues/32437#issuecomment -498937169
• https://github.com/golang/go/issues/32437#issuecomment -498967099
• https://github.com/golang/go/issues/32437#issuecomment -499194787
• https://github.com/golang/go/issues/32437#issuecomment -499309304

これら2つの異議に対する反論はそれぞれ次のとおりです。

1. 「[名前付き結果パラメーター]は問題ないと判断しました」
2. 「誰もあなたにtryを使わせるつもりはない」/ 100％の場合には適切ではない

私は1について何も言うことはありません（私はそれについて強く感じていません）。 しかし、2に関しては、8月の提案にはこの問題がなかったことに注意しますが、ほとんどの反対の提案にもこの問題はありません。

特に、 tryfの反対提案（このスレッドで2回独立して投稿された）もtry(X, handlefn)の反対提案（設計の反復の一部でした）にもこの問題はありませんでした。

tryは、それ自体が、関連するコンテキストでエラーを装飾することから、単一の一般的な関数ごとのエラー装飾に向かって人々を押しやるということを主張するのは難しいと思います。

これらの理由から、この問題に取り組む価値があると思います。可能な解決策を提案したいと思います。

1. 現在、 deferのパラメーターは、関数またはメソッドの呼び出しのみです。 deferにも関数名または関数リテラルを含めることができます。

defer func(...) {...}
defer packageName.functionName

1. パニックまたはdeferreturnがこのタイプの遅延に遭遇すると、すべてのパラメーターにゼロ値を渡す関数を呼び出します。

2. tryに複数のパラメーターを含めることを許可する

3. tryが新しいタイプの遅延に遭遇すると、最初のパラメーターとしてエラー値へのポインターを渡し、その後に最初のパラメーターを除くすべてのtry自身のパラメーターを渡す関数を呼び出します。

たとえば、次のようになります。

func errorfn() error {
    return errors.New("an error")
}


func f(fail bool) {
    defer func(err *error, a, b, c int) {
        fmt.Printf("a=%d b=%d c=%d\n", a, b, c)
    }
    if fail {
        try(errorfn, 1, 2, 3)
    }
}

次のことが起こります。

f(false)        // prints "a=0 b=0 c=0"
f(true)         // prints "a=1 b=2 c=3"

@zeeboによるhttps://github.com/golang/go/issues/32437#issuecomment-499309304のコードは、次のように書き直すことができます。

func (c *Config) Build() error {
    defer func(err *error, msg string, args ...interface{}) {
        if *err == nil || msg == "" {
            return
        }
        *err = errors.WithMessagef(err, msg, args...)
    }
    pkgPath := try(c.load(), "load config dir")

    b := bytes.NewBuffer(nil)
    try(templates.ExecuteTemplate(b, "main", c), "execute main template")

    buf := try(format.Source(b.Bytes()), "format main template")

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    try(ioutil.WriteFile(target, buf, 0644), "write file %s", target)
    // ...
}

そして、ErrorHandlefを次のように定義します。

func HandleErrorf(err *error, format string, args ...interface{}) {
        if *err != nil && format != "" {
                *err = fmt.Errorf(format + ": %v", append(args, *err)...)
        }
}

fmtスタイルの文字列をコア言語に取り込むことなく、誰もが求めるtryfを無料で提供します。

deferは引数として関数式を許可しないため、この機能には下位互換性があります。 新しいキーワードは導入されていません。
https://github.com/golang/proposal/blob/master/design/32437-try-builtin.mdで概説されているものに加えて、それを実装するために行う必要のある変更は次のとおりです。

1. 新しい種類の延期についてパーサーに教える
2. タイプチェッカーを変更して、関数内で（呼び出しではなく）パラメーターとして関数を持つすべてのdeferも同じ署名を持っていることを確認します
3. タイプチェッカーを変更して、 tryに渡されたパラメーターがdeferに渡された関数のシグネチャと一致することを確認します
4. バックエンド（？）を変更して、適切なdeferproc呼び出しを生成します
5. tryの実装を変更して、新しい種類の延期によって延期された呼び出しに遭遇したときに、その引数を延期された呼び出しの引数にコピーします。

check/handleドラフト設計の複雑さの後で、これほど単純で実用的な提案の土地を見て、私はうれしく驚きましたが、それに対して多くの反発があったことに失望しました。

確かに、多くの反発は、現在の冗長性（完全に合理的な立場）に非常に満足しており、おそらくそれを軽減するための提案を本当に歓迎しない人々から来ています。 残りの私たちにとって、この提案は、シンプルでGoに似ているというスイートスポットに当たると思います。あまり多くのことをしようとせず、 tryの場合に常にフォールバックできる既存のエラー処理手法とうまく調和します。

いくつかの特定の点について：

1. この提案で私が嫌うのは、 deferを使用するときに名前付きのエラー戻りパラメーターが必要なことだけですが、それでも、他の解決策とは相容れないものは考えられません。言語の残りの部分が機能する方法。 ですから、提案が採択されれば、これを受け入れなければならないと思います。

2. tryが、エラー値を返さない関数のテストパッケージでうまく機能しないのは残念です。 これに対する私自身の好ましい解決策は、nil以外のエラーが発生したときに返されるのではなく、常にパニックになる2番目の組み込み関数（おそらくptryまたはmust ）を持つことです。前述の関数（ mainを含む）で使用されます。 このアイデアは現在の提案の反復では却下されましたが、私はそれが「緊密な呼びかけ」であるという印象を形成したため、再検討の対象となる可能性があります。

3. go try(f)またはdefer try(f)が行っていることに頭を悩ませることは難しいので、完全に禁止するのが最善だと思います。

4. go fmtが1行のifステートメントを書き直さなかった場合、既存のエラー処理手法はそれほど冗長に見えないと考える人たちに同意します。 個人的には、エラー処理に関係するかどうかに関係なく、これが_any_単一ステートメントifに対して許可されるという単純なルールを好みます。 実際、宣言が許可されているのと同じ行に本文が配置されている単一行関数を作成するときに、これが現在許可されていない理由を理解できませんでした。

エラーを飾る場合

func myfunc()( err error){
try(thing())
defer func(){
err = errors.Wrap(err,"more context")
}()
}

これは、既存のパラダイムよりもかなり冗長で苦痛を感じ、チェック/処理ほど簡潔ではありません。 ラップしないtry（）バリアントはより簡潔ですが、人々がtryを組み合わせて使用​​することになり、単純なエラーが返されるように感じます。 tryと単純なエラーリターンを組み合わせるというアイデアが好きかどうかはわかりませんが、エラーの装飾で完全に売り切れています（そしてIs / Asを楽しみにしています）。 これは構文的にはきれいですが、実際に使用したいかどうかはわかりません。 チェック/ハンドルは、私がもっと徹底的に受け入れる何かを感じました。

私はこれの単純さと「1つのことをうまくやる」アプローチが本当に好きです。 私のGoAWKインタープリターでは、非常に役立ちます。単純化して整理できる約100個のif err != nil { return nil }構造があり、それはかなり小さなコードベースにあります。

キーワードではなく組み込みにするという提案の正当性を読みましたが、結局、パーサーを調整する必要はありません。 しかし、コンパイラーとツールの作成者にとっては比較的小さな苦痛ではありませんが、余分な親子とこれは関数のように見えますが、読みやすさの問題はすべてGoコーダーとコード-読者は耐えなければなりません。 私の意見では、「しかしpanic()はフローを制御する」という議論（言い訳？:-)はそれをカットしません。なぜなら、パニックと回復は本質的に例外的であるのに対し、 try()は通常のエラー処理と制御フローである。

これがそのまま行われたとしても、間違いなくありがたいですが、私の強い好みは、通常の制御フローを明確にすること、つまりキーワードを介して行うことです。

私はこの提案に賛成です。 それは前の提案についての私の最大の予約を避けます： deferに関してhandleの非直交性。

上で強調されていないと思う2つの側面について言及したいと思います。

まず、この提案では、コンテキスト固有のエラーテキストをエラーに追加するのは簡単ではありませんが、スタックフレームのエラー追跡情報をエラーに追加するのは簡単です：https： //play.golang.org/p / YL1MoqR08E6

第二に、 tryは、 https：//github.com/golang/go/issues/19642の根底にある問題のほとんどに対する間違いなく公正な解決策です。 その問題の例をとると、 tryを使用して、毎回すべての戻り値を書き出さないようにすることができます。 これは、長い名前を持つ値による構造体型を返すときにも役立つ可能性があります。

func (f *Font) viewGlyphData(b *Buffer, x GlyphIndex) (buf []byte, offset, length uint32, err error) {
    xx := int(x)
    if f.NumGlyphs() <= xx {
        try(ErrNotFound)
    }
    i := f.cached.locations[xx+0]
    j := f.cached.locations[xx+1]
    if j < i {
        try(errInvalidGlyphDataLength)
    }
    if j-i > maxGlyphDataLength {
        try(errUnsupportedGlyphDataLength)
    }
    buf, err = b.view(&f.src, int(i), int(j-i))
    return buf, i, j - i, err
}

私もこの提案が好きです。

そして、お願いがあります。

makeのように、 tryが可変数のパラメーターを取ることを許可できますか？

• try（f）：
  上記のように。
  戻りエラー値は必須です（最後の戻りパラメーターとして）。
  最も一般的な使用モデル
• try（f、doPanic bool）：
  上記と同じですが、doPanicの場合、戻る代わりにpanic（err）になります。
  このモードでは、戻りエラー値は必要ありません。
• try（f、fn）：
  上記と同じですが、戻る前にfn（err）を呼び出します。
  このモードでは、戻りエラー値は必要ありません。

このように、それは明示的でありながら、すべてのユースケースを処理できる1つの組み込みです。 その利点：

• 常に明示的-パニックになるか、エラーを設定して戻るかを推測する必要はありません
• コンテキスト固有のハンドラーをサポートします（ただし、ハンドラーチェーンはサポートしません）
• エラー戻り変数がないユースケースをサポートします
• must（...）セマンティクスをサポート

繰り返しのif err !=nil { return ... err }は確かに醜い吃音ですが、私はそれらと一緒です
try（）の提案は読みやすさが非常に低く、やや不明瞭だと思う人。
名前付きリターンの使用にも問題があります。

この種の整理が必要な場合は、糖衣構文としてtry(err)を使用してみませんか。
if err !=nil { return err } ：

file, err := os.Open("file.go")
try(err)

ために

file, err := os.Open("file.go")
if err != nil {
   return err
}

また、戻り値が複数ある場合、 try(err)はreturn t1, ... tn, errになる可能性があります
ここで、t1、... tnは、他の戻り値のゼロ値です。

この提案により、名前付きの戻り値が不要になり、次のようになります。
私の見解では、理解しやすく、読みやすくなっています。

さらに良いことに、私は次のようになると思います：

file, try(err) := os.Open("file.go")

あるいは

file, err? := os.Open("file.go")

この最後は下位互換性があります（？は現在識別子では許可されていません）。

（この提案はhttps://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring-themesに関連しています。しかし、繰り返しのテーマの例は、明示的なハンドルが離れるのではなくまだ議論されていた段階であったため、異なっているように見えますそれを延期します。）

この慎重で興味深い提案をしてくれたgoチームに感謝します。

@rogpeppeコメントtryがスタックフレームを自動追加する場合、私ではなく、コンテキストの追加を思いとどまらせても大丈夫です。

@ aarzilli-それで、あなたの提案によれば、 tryfに追加のパラメーターを与えるたびにdefer句は必須ですか？

するとどうなりますか

try(ioutil.WriteFile(target, buf, 0644), "write file %s", target)

と延期関数を書かないのですか？

@agnivade

（...）延期関数を記述しないとどうなりますか？

タイプチェックエラー。

私の意見では、すべての戻り値を書き出さないようにtryを使用することは、実際にはそれに対する別の攻撃です。

func (f *Font) viewGlyphData(b *Buffer, x GlyphIndex) (buf []byte, offset, length uint32, err error) {
    xx := int(x)
    if f.NumGlyphs() <= xx {
        try(ErrNotFound)
    }
    //...

return nil, 0, 0, ErrNotFoundを書き出さなくてもいいという願望は完全に理解していますが、それを別の方法で解決したいと思います。

tryという言葉は、「返品」を意味するものではありません。 そして、それがここで使用されている方法です。 tryがerrorの値を直接受け取れないように、提案を変更することを実際に望んでいます。なぜなら、そのようなコードを誰かに書いてほしくないからです^^。 読み間違えます。 あなたがそのコードを初心者に見せた場合、彼らはその試みが何をしていたのか見当がつかないでしょう。

デフォルトとエラー値を簡単に返す方法が必要な場合は、それを個別に解決しましょう。 多分別のビルトインのような

return default(ErrNotFound)

少なくとも、それはある種のロジックで読み取られます。

しかし、他の問題を解決するためにtryを悪用しないようにしましょう。

@natefinch元の提案のようにtryビルトインの名前がcheckの場合、 check(err)になり、かなり読みやすくなります。

それはさておき、 try(err)を書くことが本当に虐待であるかどうかはわかりません。 それはきれいに定義から外れます。 しかし、一方で、これは合法であることも意味します。

a, b := try(1, f(), err)

tryに関する私の主な問題は、実際には1レベルしか上がらないpanicであるということだと思います...パニックとは異なり、ステートメントではなく式であるため、非表示にできますそれはどこかのステートメントの途中にあります。 それはほとんどパニックよりも悪くなります。

@natefinchあるレベルに上がってから他のことをするパニックのように概念化すると、かなり厄介に思えます。 しかし、私はそれを別の方法で概念化しています。 Goでエラーを返す関数は、効果的に結果を返します、Rustの用語から大まかに借用します。 tryは、結果を解凍し、 error != nilの場合は「エラー結果」を返すか、 error == nilの場合は結果のT部分を解凍するユーティリティです。

もちろん、Goには実際には結果オブジェクトはありませんが、事実上同じパターンであり、 tryはそのパターンの自然な成文化のようです。 この問題の解決策は、エラー処理のいくつかの側面を成文化する必要があると私は信じており、 tryがそれを引き受けることは私には合理的であるように思われます。 私自身と他の人は、既存のGoエラー処理パターンによりよく適合するようにtryの機能を少し拡張することを提案していますが、基本的な概念は同じままです。

@ugorji提案するtry(f, bool)バリアントは、＃32219のmustのように聞こえます。

@ugorji提案するtry(f, bool)バリアントは、＃32219のmustのように聞こえます。

はい、そうです。 3つのケースすべてが単一の組み込み関数で処理でき、すべてのユースケースをエレガントに満たすことができると感じました。

try()はすでに魔法のようであり、エラーの戻り値を認識しているので、nullary（ゼロ引数）形式で呼び出されたときにその値へのポインターも返すように拡張できますか？ これにより、名前付きの返品が不要になり、deferステートメントでエラーが発生すると予想される場所を視覚的に関連付けるのに役立つと思います。 例えば：

func foo() error {
  defer fmt.HandleErrorf(try(), "important foo context info")
  try(bar())
  try(baz())
  try(etc())
}

@ugorji
try(f, bool)のブール値は、読みにくく、見逃しやすいと思います。 私はあなたの提案が好きですが、パニックの場合、ユーザーが3番目の箇条書きからハンドラー内にそれを書くことを省略できると思います（例： try(f(), func(err error) { panic('at the disco'); }) ）。これにより、非表示のtry(f(), true)よりもユーザーにとってより明確になります

@ugorji
try(f, bool)のブール値は、読みにくく、見逃しやすいと思います。 私はあなたの提案が好きですが、パニックの場合、ユーザーが3番目の箇条書きからハンドラー内にそれを書くことを省略できると思います（例： try(f(), func(err error) { panic('at the disco'); }) ）。これにより、非表示のtry(f(), true)よりもユーザーにとってより明確になります

さらに考えてみると、私はあなたの立場とあなたの推論に同意する傾向があります、そしてそれはまだワンライナーとしてエレガントに見えます。

@ patrick-nytは、 https： //github.com/golang/go/issues/32437#issuecomment -499533464で、nilテストをトリガーする_assignment構文_のもう1つの提案者です。

この概念は、チェック/ハンドル提案に対する13の個別の応答に表示されます
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes

f, ?return := os.Open(...)
f, ?panic  := os.Open(...)

なんで？ Go 1のように読み取られるのに対し、 try()とcheckはそうではありません。

https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md#draft -design

tryに対する1つの異議は、それが式であるということのようです。 代わりに、nilでない場合はreturnを意味する単項postfixステートメント?があるとします。 これが標準のコードサンプルです（提案された遅延パッケージが追加されたと仮定します）：

func CopyFile(src, dst string) error {
    var err error // Don't need a named return because err is explicitly named
    defer deferred.Annotate(&err, "copy %s %s", src, dst)

    r, err := os.Open(src)
    err?
    defer deferred.AnnotatedExec(&err, r.Close)

    w, err := os.Create(dst)
    err?
    defer deferred.AnnotatedExec(&err, r.Close)

    defer deferred.Cond(&err, func(){ os.Remove(dst) })
    _, err = io.Copy(w, r)

    return err
}

pgStoreの例：

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    err?

    defer deferred.Cond(&err, func(){ tx.Rollback() })

    var res int64 
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    // tricky bit: this would not change the value of err 
    // but the deferred.Cond would still be triggered by err being set before
    deferred.Format(err, "insert table")?

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    deferred.Format(err, "insert table2")?

    return tx.Commit()
}

私は@jargvからこれが好きです：

try（）はすでに魔法のようであり、エラーの戻り値を認識しているので、nullary（ゼロ引数）形式で呼び出されたときにその値へのポインターも返すように拡張できますか？ これにより、名前付き返品が不要になります

しかし、引数の数に基づいて名前tryをオーバーロードする代わりに、 reterrなどの別の魔法が組み込まれている可能性があると思います。

私はいくつかの非常に頻繁に使用されるパッケージについて簡単に説明し、エラー処理に「苦しむ」が、書く前によく考えられていたはずのgoコードを探し、提案されたtry（）が何をするかを理解しようとしました。
現在、私が提案を誤解しない限り、それらの多く（たとえば、超基本的なエラー処理ではない）はあまり得られないか、「古い」エラー処理スタイルを維持する必要があります。
net / http / request.goからの例：

func (r *Request) write(w io.Writer, usingProxy bool, extraHeaders Header, waitForContinue func() bool) (err error) {
`

trace := httptrace.ContextClientTrace(r.Context())
if trace != nil && trace.WroteRequest != nil {
    defer func() {
        trace.WroteRequest(httptrace.WroteRequestInfo{
            Err: err,
        })
    }()
}

// Find the target host. Prefer the Host: header, but if that
// is not given, use the host from the request URL.
//
// Clean the host, in case it arrives with unexpected stuff in it.
host := cleanHost(r.Host)
if host == "" {
    if r.URL == nil {
        return errMissingHost
    }
    host = cleanHost(r.URL.Host)
}

// According to RFC 6874, an HTTP client, proxy, or other
// intermediary must remove any IPv6 zone identifier attached
// to an outgoing URI.
host = removeZone(host)

ruri := r.URL.RequestURI()
if usingProxy && r.URL.Scheme != "" && r.URL.Opaque == "" {
    ruri = r.URL.Scheme + "://" + host + ruri
} else if r.Method == "CONNECT" && r.URL.Path == "" {
    // CONNECT requests normally give just the host and port, not a full URL.
    ruri = host
    if r.URL.Opaque != "" {
        ruri = r.URL.Opaque
    }
}
if stringContainsCTLByte(ruri) {
    return errors.New("net/http: can't write control character in Request.URL")
}
// TODO: validate r.Method too? At least it's less likely to
// come from an attacker (more likely to be a constant in
// code).

// Wrap the writer in a bufio Writer if it's not already buffered.
// Don't always call NewWriter, as that forces a bytes.Buffer
// and other small bufio Writers to have a minimum 4k buffer
// size.
var bw *bufio.Writer
if _, ok := w.(io.ByteWriter); !ok {
    bw = bufio.NewWriter(w)
    w = bw
}

_, err = fmt.Fprintf(w, "%s %s HTTP/1.1\r\n", valueOrDefault(r.Method, "GET"), ruri)
if err != nil {
    return err
}

// Header lines
_, err = fmt.Fprintf(w, "Host: %s\r\n", host)
if err != nil {
    return err
}
if trace != nil && trace.WroteHeaderField != nil {
    trace.WroteHeaderField("Host", []string{host})
}

// Use the defaultUserAgent unless the Header contains one, which
// may be blank to not send the header.
userAgent := defaultUserAgent
if r.Header.has("User-Agent") {
    userAgent = r.Header.Get("User-Agent")
}
if userAgent != "" {
    _, err = fmt.Fprintf(w, "User-Agent: %s\r\n", userAgent)
    if err != nil {
        return err
    }
    if trace != nil && trace.WroteHeaderField != nil {
        trace.WroteHeaderField("User-Agent", []string{userAgent})
    }
}

// Process Body,ContentLength,Close,Trailer
tw, err := newTransferWriter(r)
if err != nil {
    return err
}
err = tw.writeHeader(w, trace)
if err != nil {
    return err
}

err = r.Header.writeSubset(w, reqWriteExcludeHeader, trace)
if err != nil {
    return err
}

if extraHeaders != nil {
    err = extraHeaders.write(w, trace)
    if err != nil {
        return err
    }
}

_, err = io.WriteString(w, "\r\n")
if err != nil {
    return err
}

if trace != nil && trace.WroteHeaders != nil {
    trace.WroteHeaders()
}

// Flush and wait for 100-continue if expected.
if waitForContinue != nil {
    if bw, ok := w.(*bufio.Writer); ok {
        err = bw.Flush()
        if err != nil {
            return err
        }
    }
    if trace != nil && trace.Wait100Continue != nil {
        trace.Wait100Continue()
    }
    if !waitForContinue() {
        r.closeBody()
        return nil
    }
}

if bw, ok := w.(*bufio.Writer); ok && tw.FlushHeaders {
    if err := bw.Flush(); err != nil {
        return err
    }
}

// Write body and trailer
err = tw.writeBody(w)
if err != nil {
    if tw.bodyReadError == err {
        err = requestBodyReadError{err}
    }
    return err
}

if bw != nil {
    return bw.Flush()
}
return nil

}
`

または、pprof / profile /profile_test.goなどの徹底的なテストで使用されます。
`
func checkAggregation（prof * Profile、* aggTest）エラー{
//行のサンプルの総数が保持されていることを確認します。
合計：= int64（0）

samples := make(map[string]bool)
for _, sample := range prof.Sample {
    tb := locationHash(sample)
    samples[tb] = true
    total += sample.Value[0]
}

if total != totalSamples {
    return fmt.Errorf("sample total %d, want %d", total, totalSamples)
}

// Check the number of unique sample locations
if a.rows != len(samples) {
    return fmt.Errorf("number of samples %d, want %d", len(samples), a.rows)
}

// Check that all mappings have the right detail flags.
for _, m := range prof.Mapping {
    if m.HasFunctions != a.function {
        return fmt.Errorf("unexpected mapping.HasFunctions %v, want %v", m.HasFunctions, a.function)
    }
    if m.HasFilenames != a.fileline {
        return fmt.Errorf("unexpected mapping.HasFilenames %v, want %v", m.HasFilenames, a.fileline)
    }
    if m.HasLineNumbers != a.fileline {
        return fmt.Errorf("unexpected mapping.HasLineNumbers %v, want %v", m.HasLineNumbers, a.fileline)
    }
    if m.HasInlineFrames != a.inlineFrame {
        return fmt.Errorf("unexpected mapping.HasInlineFrames %v, want %v", m.HasInlineFrames, a.inlineFrame)
    }
}

// Check that aggregation has removed finer resolution data.
for _, l := range prof.Location {
    if !a.inlineFrame && len(l.Line) > 1 {
        return fmt.Errorf("found %d lines on location %d, want 1", len(l.Line), l.ID)
    }

    for _, ln := range l.Line {
        if !a.fileline && (ln.Function.Filename != "" || ln.Line != 0) {
            return fmt.Errorf("found line %s:%d on location %d, want :0",
                ln.Function.Filename, ln.Line, l.ID)
        }
        if !a.function && (ln.Function.Name != "") {
            return fmt.Errorf(`found file %s location %d, want ""`,
                ln.Function.Name, l.ID)
        }
    }
}

return nil

}
`
これらは私が考えることができる2つの例であり、「より良いエラー処理オプションが欲しい」と言うでしょう。

誰かがtry（）を使用してこれらがどのように改善されるかを示すことができますか？

私は主にこの提案に賛成です。

多くのコメント投稿者と共有されている私の主な関心事は、名前付きの結果パラメーターに関するものです。 現在の提案は確かに名前付き結果パラメータのより多くの使用を奨励しており、それは間違いだと思います。 提案が述べているように、これは単にスタイルの問題ではないと思います。名前付きの結果は言語の微妙な特徴であり、多くの場合、コードがバグを起こしやすいか、不明瞭になります。 Goコードの読み取りと書き込みを約8年間行った後、私は実際には2つの目的で名前付き結果パラメーターのみを使用します。

• 結果パラメータの文書化
• 延期内の結果値（通常はerror ）の操作

この問題を新しい方向から攻撃するために、これは、設計ドキュメントまたはこの問題のコメントスレッドで説明されているものと密接に一致するとは思わないアイデアです。 それを「エラーディフ​​ァー」と呼びましょう。

暗黙のエラーパラメータを使用して関数を呼び出すためにdeferを使用できるようにします。

だからあなたが機能を持っているなら

func f(err error, t1 T1, t2 T2, ..., tn Tn) error

次に、最後の結果パラメーターの型がerrorである関数g $（つまり、 tryが使用される関数）で、 fを呼び出します。次のように延期される場合があります。

func g() (R0, R0, ..., error) {
    defer f(t0, t1, ..., tn) // err is implicit
}

error-deferのセマンティクスは次のとおりです。

1. fへの遅延呼び出しは、 fの最初の入力パラメーターとしてgの最後の結果パラメーターを使用して呼び出されます。
2. fは、そのエラーがnilでない場合にのみ呼び出されます
3. fの結果は、 gの最後の結果パラメーターに割り当てられます。

したがって、古いエラー処理設計ドキュメントの例を使用して、error-deferを使用して試してみると、次のことができます。

func printSum(a, b string) error {
    defer func(err error) error {
        return fmt.Errorf("printSum(%q + %q): %v", a, b, err)
    }()
    x := try(strconv.Atoi(a))
    y := try(strconv.Atoi(b))
    fmt.Println("result:", x+y)
    return nil
}

HandleErrorfの動作は次のとおりです。

func printSum(a, b string) error {
    defer handleErrorf("printSum(%q + %q)", a, b)
    x := try(strconv.Atoi(a))
    y := try(strconv.Atoi(b))
    fmt.Println("result:", x+y)
    return nil
}

func handleErrorf(err error, format string, args ...interface{}) error {
    return fmt.Errorf(format+": %v", append(args, err)...)
}

解決する必要がある1つのコーナーケースは、使用している延期の形式があいまいな場合の処理​​方法です。 これは、次のようなシグネチャを持つ（非常に珍しい）関数でのみ発生すると思います。

func(error, ...error) error

このケースはエラー遅延のない方法で処理されると言うのが妥当なようです（これにより下位互換性が維持されます）。

この数日間このアイデアについて考えると、少し魔法のようですが、名前付きの結果パラメーターを回避することは、その利点として大きな利点です。 tryは、エラー操作のためのdeferの使用を促進するため、 deferをその目的により適したものに拡張できることは理にかなっています。 また、 tryとエラーディフ​​ァーの間には一定の対称性があります。

最後に、エラーディフ​​ァーは、エラーリターンを操作するための名前付き結果パラメーターの使用に取って代わるため、試行しなくても今日は便利です。 たとえば、実際のコードの編集バージョンは次のとおりです。

// GetMulti retrieves multiple files through the cache at once and returns its
// results as a slice parallel to the input.
func (c *FileCache) GetMulti(keys []string) (_ []*File, err error) {
    files := make([]*file, len(keys))

    defer func() {
        if err != nil {
            // Return any successfully retrieved files.
            for _, f := range files {
                if f != nil {
                    c.put(f)
                }
            }
        }
    }()

    // ...
}

エラーディフ​​ァーを使用すると、これは次のようになります。

// GetMulti retrieves multiple files through the cache at once and returns its
// results as a slice parallel to the input.
func (c *FileCache) GetMulti(keys []string) ([]*File, error) {
    files := make([]*file, len(keys))

    defer func(err error) error {
        // Return any successfully retrieved files.
        for _, f := range files {
            if f != nil {
                c.put(f)
            }
        }
        return err
    }()

    // ...
}

@beoranジェネリックを待つべきだというあなたのコメントについて。 ジェネリックスはここでは役に立ちません-FAQを読んでください。

@velovixの2つの引数tryのデフォルトの動作に関する提案について：前に述べたように、明らかに合理的な選択が何であるかについてのあなたの考えは、他の誰かの悪夢です。

明示的なエラーハンドラを使用したtryは、現在の最小のtryよりも優れているという幅広いコンセンサスが得られたら、この議論を続けることをお勧めします。 その時点で、そのような設計の細かい点について議論することは理にかなっています。

（私はハンドラーを持つのが好きです。それは以前の提案の1つです。 tryをそのまま採用した場合でも、ハンドラーを前方に配置してtryに移行できます。 -互換性のある方法-少なくともハンドラーがオプションの場合。ただし、一度に1ステップずつ実行しましょう。）

@aarzilliご提案ありがとうございます。

エラーの装飾がオプションである限り、人々はそれを行わないことに傾倒します（結局のところ、それは余分な作業です）。 こちらの私のコメントも参照してください。

したがって、提案されたtry _discourages_の人々がエラーを飾ることを思いとどまらせるとは思いません（上記の理由でifを使用しても、すでに落胆しています）。 tryはそれを_奨励_しないということです。

（それを奨励する1つの方法は、それをtryに結び付けることです。エラーを装飾するか、明示的にオプトアウトする場合にのみ、 tryを使用できます。）

しかし、あなたの提案に戻ってください。あなたはここでもっとたくさんの機械を導入していると思います。 deferのセマンティクスを変更して、 tryでより適切に機能させることは、それらのdeferの変更がより一般的な方法で有益でない限り、検討したいことではありません。 また、あなたの提案はdeferをtryと結び付けているため、これらのメカニズムの直交性が低くなります。 避けたいもの。

しかし、もっと重要なことは、 tryを使用できるようにするためだけに、全員にdeferを強制的に記述させたいとは思わないことです。 しかし、それを行わずに、私たちは正方に戻ります。人々はエラーを装飾しないことに傾倒します。

（私はハンドラーを持っているのが好きです。それは私たちの以前の提案の1つです。そして、そのままtryを採用した場合でも、少なくともハンドラーがオプションですが、一度に1ステップずつ実行しましょう。）

確かに、おそらく多段階のアプローチが進むべき道です。 将来、オプションのハンドラー引数を追加すると、 errcheckツールと同じ精神で、未処理のtryをライターに警告するツールを作成できます。 とにかく、私はあなたのフィードバックに感謝します！

@alanfoあなたの正のフィードバックをありがとう。

あなたが提起したポイントについて：

1） tryの唯一の問題が、 deferを介してエラーを装飾できるように、エラーリターンに名前を付ける必要があるという事実である場合、私たちは良いと思います。 結果に名前を付けることが実際の問題であることが判明した場合は、それに対処できます。 私が考えることができる単純なメカニズムは、エラー結果のエイリアスである事前に宣言された変数です（最新のtryをトリガーしたエラーを保持していると考えてください）。 より良いアイデアがあるかもしれません。 結果に名前を付けるというメカニズムが言語にすでに存在するため、これを提案しませんでした。
2） tryとテスト：これに対処して機能させることができます。 詳細なドキュメントを参照してください。
3）これは詳細なドキュメントで明示的に扱われています。
4）確認済み。

@benhoytあなたの正のフィードバックをありがとう。

この提案に対する主な議論がtryが組み込みであるという事実である場合、私たちは素晴らしい場所にいます。 組み込みを使用することは、下位互換性の問題に対する実用的な解決策にすぎません（パーサーやツールなどに余分な作業が発生することはありませんが、これは主な理由ではなく、単なる優れた副次的な利点です）。 括弧を書かなければならないことにはいくつかの利点もあります。これについては、設計ドキュメント（提案された設計のプロパティに関するセクション）で詳しく説明されています。

とはいえ、ビルトインを使用することがショートッパーである場合は、 tryキーワードを検討する必要があります。 キーワードが既存の識別子と競合する可能性があるため、既存のコードとの下位互換性はありません。

（完全を期すために、下位互換性のある?などの演算子のオプションもあります。ただし、Goなどの言語の最良の選択とは言えません。しかし、繰り返しになりますが、 tryを美味しくするために必要なのはそれだけなら、おそらくそれを検討する必要があります。）

@ugorjiあなたの正のフィードバックをありがとう。

tryを拡張して、追加の引数を取ることができます。 私たちの好みは、シグネチャfunc (error) errorを持つ関数のみを取ることです。 パニックに陥りたい場合は、1行のヘルパー関数を簡単に提供できます。

func doPanic(err error) error { panic(err) }

tryのデザインをシンプルに保つ方が良いでしょう。

@ patrick-nytあなたが提案していること：

file, err := os.Open("file.go")
try(err)

現在の提案で可能になります。

@ dpinela 、 @ ugorji mustとtryのテーマに関する設計ドキュメントもお読みください。 tryはできるだけシンプルに保つことをお勧めします。 mustは初期化式の一般的な「パターン」ですが、それを「修正」する緊急の必要はありません。

@jargvご提案ありがとうございます。 これは興味深いアイデアです（このテーマに関する私のコメントも参照してください）。 要約する：

• try(x)は提案どおりに動作します
• try()は、エラー結果を指す*error $を返します

これは、名前を付けることなく結果を得る別の方法です。

@cespare @jargvによる提案は、あなたが提案しているものよりもはるかに単純に見えます。 結果エラーへのアクセスの同じ問題を解決します。 どう思いますか？

https://github.com/golang/go/issues/32437#issuecomment -499320588によると：

func doPanic（err error）error {panic（err）}

この機能はかなり一般的だと思います。 これは「ビルトイン」（または標準パッケージの他の場所、たとえばerrors ）で事前定義できますか？

実装するのに十分強力なジェネリックを期待していないのは残念です
試してみてください、私は実際にそうすることが可能になることを望んでいたでしょう。

はい、この提案は最初のステップになる可能性がありますが、
それは今の自分自身です。

確かに、この問題はおそらく詳細な代替案に焦点を当てすぎています。
しかし、それは多くの参加者が完全に満足していないことを示しています
それ。 欠けているように見えるのは、この提案についての幅広いコンセンサスです...

Op vr 7jun。 2019 01:04 schreef [email protected] ：

Asper＃32437（コメント）
https://github.com/golang/go/issues/32437#issuecomment-499320588 ：

func doPanic（err error）error {panic（err）}

この機能はかなり一般的だと思います。 これは事前定義できますか
「ビルトイン」で？

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/32437?email_source=notifications&email_token=AAARM6OOOLLYO5ZCE6VVL2TPZGJWRA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2Z
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAARM6K5AOR2DES4QDTNLSTPZGJWRANCNFSM4HTGCZ7Q
。

@pjebs 、私は同等の関数を何十回も書いてきました。 私は通常それを「orDie」または「check」と呼びます。 とてもシンプルなので、標準ライブラリの一部にする必要はありません。 さらに、さまざまな人々が、終了前にロギングなどを必要とする場合があります。

@beoranおそらく、ジェネリックスとエラー処理の間の関係を拡張することができます。 私がそれらについて考えるとき、それらは2つの異なるもののように見えます。 ジェネリックスは、言語に関するすべての問題に対処できるすべてを網羅しているわけではありません。 これは、複数のタイプを操作できる単一の関数を作成する機能です。

この特定のエラー処理の提案は、状況によってはフロー制御を変更する事前に宣言された関数tryを導入することにより、ボイラープレートを削減しようとします。 ジェネリックは制御の流れを変えることはありません。 だから私は本当に関係を見ていません。

これに対する私の最初の反応は👎でした。関数内でエラーが発生しやすいいくつかの呼び出しを処理すると、 deferエラーハンドルが混乱することを想像していました。 提案全体を読んだ後、私は❤️と👍への反応を反転させました。これは、比較的低い複雑さでまだ達成できることを学びました。

@carlmjohnsonはい、それは簡単ですが...

私は同等の関数を何十回も書いてきました。

事前に宣言された関数の利点は次のとおりです。

1. 一列に並べることができます
2. 使用するすべてのパッケージでerr => panic関数を再宣言したり、共通の場所を維持したりする必要はありません。 おそらくGoコミュニティのすべての人に共通しているので、「標準パッケージ」は___共通の場所です。

@griesemer元のtryプロポーザルのエラーハンドラバリアントでは、エラーを返すための包括的な関数の要件は不要になりました。

私が最初にそれについて尋ねたとき、err =>パニック、提案はそれを考慮したが、それは危険すぎると考えた（正当な理由で）と指摘されました。 しかし、包括的な関数がエラーを返さないシナリオでエラーハンドラーなしでtry()を使用する場合、コンパイル時エラーにすることで、提案で説明されている懸念が軽減されます。

@pjebs元の設計では、エラーを返すための包括的な関数の要件は必要ありませんでした。エラーハンドラが提供されていた場合。 しかし、それはtryのもう1つの複雑さです。 シンプルに保つ方が_はるかに_良いです。 代わりに、別のmust関数を使用する方が明確です。この関数は、エラーが発生すると常にパニックになります（ただし、それ以外の場合はtryのようになります）。 そうすれば、コードで何が起こるかは明らかであり、コンテキストを調べる必要はありません。

このようなmustを持つことの主な魅力は、単体テストで使用できることです。 特に、 testingパッケージが、 mustによって引き起こされたパニックから回復し、テストの失敗として適切に報告するように適切に調整されている場合。 しかし、 TestXxx(t *testing.T) errorの形式のテスト関数も受け入れるようにテストパッケージを調整できるのに、なぜさらに別の新しい言語メカニズムを追加するのでしょうか。 結局のところ非常に自然に見えるエラーが返された場合（おそらく最初からこれを行う必要があります）、 tryは問題なく機能します。 ローカルテストにはもう少し作業が必要ですが、おそらく実行可能です。

mustの他の比較的一般的な使用法は、グローバル初期化式（ must(regexp.Compile...など）です。 もしそれが「持っていて良かった」とはいえ、それは必ずしも新しい言語機能に必要なレベルにそれを上げるわけではありません。

@griesemer mustがtry ＃$と漠然と関連していて、 tryの実装に向けた勢いがあることを考えると、 mustを検討するのは良いことだと思いませんか。同時に

このラウンドで議論されない場合、少なくとも3年以上（またはおそらくこれまで）、実装/真剣に検討されない可能性があります。 議論の重複は、最初から議論を始めて議論をリサイクルするよりも良いでしょう。

多くの人が、 mustがtry非常にうまく補完していると述べています。

@pjebs現在、「 tryが実装される勢い」があるようには見えません...-そして、これも2日前に投稿したばかりです。 何も決まっていない。 これに少し時間を与えましょう。

mustがtryとうまく調和していることは私たちを逃れませんが、それは言語の一部にすることと同じではありません。 私たちは、より広いグループの人々とこの空間を探索し始めたばかりです。 何が賛成か反対かはまだわかりません。 ありがとう。

すべてのコメントと詳細な設計ドキュメントを何時間も読んだ後、私はこの提案に自分の意見を追加したいと思いました。

以前のポイントを言い換えるだけでなく、ディスカッションに新しいコメントを追加するという@ianlancetaylorのリクエストを尊重するように最善を尽くします。 しかし、以前のコメントをいくらか参照せずに新しいコメントを作成することはできないと思います。

懸念

延期の不幸なオーバーロード

deferの明白でわかりやすい性質を、警戒すべきものとして過負荷にすることを好む。 defer closeFile(f)と書くと、何が起こっているのか、そしてその理由はわかりやすくわかります。 呼び出される関数の最後に。 panic()とrecover()にdeferを使用することはあまり明白ではありませんが、私はそれを使用することはめったになく、他のコードを読んでいるときにほとんど表示されません。

deferをオーバーロードしてエラーも処理するためのスプーは、明白で混乱を招くものではありません。 なぜキーワードdefer ？ deferは、_ "多分後で" _の代わりに_ "後で行う" _を意味しませんか？ "_

また、Goチームがdeferのパフォーマンスについて言及している懸念もあります。 それを考えると、 deferが_ "ホットパス" _コードフローで考慮されていることは二重に残念なことのようです。

重要なユースケースを検証する統計はありません

@prologicが述べたように、このtry()の提案は、このユースケースを使用するコードの大部分を前提としていますか、それともGoエラー処理について不満を言っている人をなだめる試みに基づいていますか？

すべてのファイルを徹底的に確認してメモを取ることなく、コードベースから統計情報を提供する方法を知っていればよかったのですが。 @prologicがどうやってできたのかはわかりませんが、彼は喜んでいました。

しかし、逸話的に、 try()が私のユースケースの5％に対応し、1％未満に対応すると思われる場合は驚きます。 他の人が大きく異なる結果をもたらすことを確かに知っていますか？ 標準ライブラリのサブセットを取得して、それがどのように適用されるかを確認しようとしましたか？

これが実際のコードの大規模なチャックに適切であるという既知の統計がないので、私が尋ねなければならないのは、新しい概念を学ぶことを誰もが必要とする言語へのこの新しい複雑な変更は、本当に魅力的な数のユースケースに対処するのですか？

開発者がエラーを無視しやすくします

これは他の人がコメントしていることの完全な繰り返しですが、基本的にtry()を提供するものは、多くの点で、以下をidomaticコードとして単純に受け入れることに類似しています。これは、どのコードにも決して入り込まないコードです。 -開発者の船を尊重する：

f, _ := os.Open(filename)

私は自分のコードでより良くなることができることを知っていますが、私たちの多くは非常に便利なパッケージを公開している他のGo開発者の大部分に依存していることも知っていますが、_ "Other People's Code（tm）" _で見たものからエラー処理のベストプラクティスは、しばしば無視されます。

真剣に、開発者がエラーを無視しやすくし、堅牢でないパッケージでGitHubを汚染できるようにしたいのでしょうか。

（ほとんど）すでにユーザーランドにtry()を実装できますか

提案を誤解しない限り（おそらくそうしますが）、ユーザーランドに実装されたGoPlaygroundのtry()ですが、戻り値は1つだけで、期待されるタイプの代わりにインターフェイスが返されます。

package main

import (
    "errors"
    "fmt"
    "strings"
)
func main() {
    defer func() {
        r := recover()
        if r != nil && strings.HasPrefix(r.(string),"TRY:") {
            fmt.Printf("Ouch! %s",strings.TrimPrefix(r.(string),"TRY: "))
        }
    }()
    n := try(badjuju()).(int)
    fmt.Printf("Just chillin %dx!",n)   
}
func badjuju() (int,error) {
    return 10, errors.New("this is a really bad error")
}
func try(args ...interface{}) interface{} {
    err,ok := args[1].(error)
    if ok && err != nil {
        panic(fmt.Sprintf("TRY: %s",err.Error()))
    }
    return args[0]
}

したがって、ユーザーは、返す必要のある戻り値の数に応じて、 try2() 、 try3()などを追加できます。

ただし、Goは、明示的な型アサーションが必要な場合でも、 try()を必要とするユーザーが独自のサポートをロールできるようにするために、1つの単純な_がユニバーサルな_言語機能のみを必要とします。 Go funcに_（完全な下位互換性）_機能を追加して、さまざまな数の戻り値を返します。例：

func try(args ...interface{}) ...interface{} {
    err,ok := args[1].(error)
    if ok && err != nil {
        panic(fmt.Sprintf("TRY: %s",err.Error()))
    }
    return args[0:len(args)-2]
}

そして、最初にジェネリックスに対処する場合、型アサーションは必要ありません_（ジェネリックスの混乱するセマンティクスと構文サラダを追加するのではなく、ジェネリックスのユースケースに対処するための組み込みを追加することによって、ジェネリックスのユースケースを削減する必要があると思いますがJavaet。al。から）_

自明性の欠如

提案のコードを調べてみると、その振る舞いは自明ではなく、推論するのがやや難しいことがわかりました。

try()が式をラップしているのを見ると、エラーが返された場合はどうなりますか？

エラーは無視されますか？ または、最初または最新のdeferにジャンプします。その場合、クロージャ内にerrという名前の変数を自動的に設定しますか、それともパラメータ_（Iパラメータが表示されませんか？）_。 また、自動エラー名でない場合、どのように名前を付けるのですか？ そして、それは、衝突を避けるために、関数で自分のerr変数を宣言できないことを意味しますか？

そして、それはすべてのdeferを呼び出しますか？ 逆順ですか、それとも通常順ですか？

それとも、クロージャとエラーが返されたfuncの両方から返されますか？ _（ここでそれを暗示する言葉を読んでいなかったら、私が考えたことのない何か。）_

提案とこれまでのすべてのコメントを読んだ後、私はまだ正直に上記の質問に対する答えを知りません。 それは、支持者が_ "キャプテンオブビシャス" _であると主張する言語に追加したい種類の機能ですか？

コントロールの欠如

deferを使用すると、開発者に与えられるコントロールは_（最新？）_ deferに分岐することだけであるように見えます。 しかし、些細なfuncを超えるメソッドを使った私の経験では、通常はそれよりも複雑です。

多くの場合、 func内、またはpackage全体でエラー処理の側面を共有すると便利ですが、1つ以上の他のパッケージ間でより具体的な処理を共有することもできます。

たとえば、別のfunc内からerror()を返す5つのfunc呼び出しを呼び出すことができます。 それらにA() 、 B() 、 C() 、 D() 、およびE()のラベルを付けましょう。 独自のエラー処理を行うにはC()が必要な場合があります。エラー処理を共有するには、 A() 、 B() 、 D() 、およびE()が必要です。 B()とE()は、特定の処理を行います。

しかし、私はこの提案でそれが可能になるとは思いません。 少なくとも簡単ではありません。

ただし、皮肉なことに、Goにはすでに、少数のユースケースに限定する必要のない高レベルの柔軟性を可能にする言語機能があります。 funcとクロージャー。 だから私の修辞的な質問は：

_ 「これらのユースケースに対処するために既存の言語にわずかな拡張を追加するだけで、新しい組み込み関数を追加したり、紛らわしいセマンティクスを受け入れる必要がないのはなぜですか？」 _

代替案として、この提案の検討中に思いついた提案を、そのすべての欠点を考慮しながら提出する予定であるため、これは修辞的な質問です。

しかし、私は逸脱します、それは後で来るでしょう、そしてこのコメントは現在の提案が再考される必要がある理由についてです。

breakに対する表明されたサポートの欠如

ほとんどの人がエラー処理にアーリーリターンを使用するため、これは左翼手から出てきたように感じるかもしれませんが、 returnの前にほとんどまたはすべての関数をラップするエラー処理にはbreakを使用することが望ましいことがわかりましたreturn 。

私はしばらくの間このアプローチを使用しており、リファクタリングだけを緩和するという利点により、初期のreturnよりも好ましいですが、単一の出口点や機能のセクションを早期に終了する機能など、他にもいくつかの利点があります。クリーンアップを実行できる_（これが、プログラムフローの観点から推論するのが難しいdeferをめったに使用しない理由です。）_

アーリーリターンの代わりにbreakを使用するには、 for range "1" {...}ループを使用して、ブレークが_から終了するためのブロックを作成します（実際には、定数のみを含むonlyというパッケージを作成しますOnceと呼ばれ、値は"1" ）：_

func (me *Config) WriteFile() (err error) {
    for range only.Once {
        var j []byte
        j, err = json.MarshalIndent(me, "", "    ")
        if err != nil {
            err = fmt.Errorf("unable to marshal config; %s", 
                err.Error(),
            )
            break
        }
        err = me.MaybeMakeDir(me.GetDir(), os.ModePerm)
        if err != nil {
            err = fmt.Errorf("unable to make directory'%s'; %s", 
                me.GetDir(), 
                err.Error(),
            )
            break
        }
        err = ioutil.WriteFile(string(me.GetFilepath()), j, os.ModePerm)
        if err != nil {
            err = fmt.Errorf("unable to write to config file '%s'; %s", 
                me.GetFilepath(), 
                err.Error(),
            )
            break
        }
    }
    return err
}

近い将来、このパターンについて詳細にブログを書き、早期の返品よりもうまく機能することがわかったいくつかの理由について話し合う予定です。

しかし、私は逸脱します。 ここで取り上げる理由は、Goがエラー処理を実装する必要があるためです。このエラー処理では、初期のreturnを想定し、エラー処理にbreakを使用することを無視します。

私の意見err == nilは問題があります

余談として、Goでの慣用的なエラー処理について感じた懸念を提起したいと思います。 私は、エラーが発生したときにエラーを処理するというGoの哲学と、例外処理を使用するという哲学を大いに信じていますが、エラーがないことを示すためにnilを使用すると、問題が発生しないことを示します。 API応答で使用するルーチンであり、エラーが発生したときにnil以外の値を返すだけではありません。

したがって、Go 2の場合、Goが新しい組み込み型のstatusと3つの組み込み関数iserror() 、 iswarning() 、 issuccess()を追加することを検討してほしいと思います。 statusはerrorを実装できます—多くの下位互換性を考慮し、 issuccess()に渡されたnil値はtrue $を返します—しかしstatusには、エラーレベルの追加の内部状態があるため、エラーレベルのテストは、常に組み込み関数の1つで実行され、理想的にはnilチェックでは実行されません。 これにより、代わりに次のようなアプローチが可能になります。

func (me *Config) WriteFile() (sts status) {
    for range only.Once {
        var j []byte
        j, sts = json.MarshalIndent(me, "", "    ")
        if iserror(sts) {
            sts.AddMessage("unable to marshal config")
            break
        }
        sts = me.MaybeMakeDir(me.GetDir(), os.ModePerm)
        if iserror(sts) {
            sts.AddMessage("unable to make directory'%s'", me.GetDir())
            break
        }
        sts = ioutil.WriteFile(string(me.GetFilepath()), j, os.ModePerm)
        if iserror(sts) {
            sts.AddMessage("unable to write to config file '%s'", 
                me.GetFilepath(), 
            )
            break
        }
        sts = fmt.Status("config file written")
    }
    return sts
}

私はすでに、エラー処理のために上記と同様のプレベータレベルの現在内部使用パッケージでユーザーランドアプローチを使用しています。 率直に言って、このアプローチを使用するときは、慣用的なGoエラー処理に従おうとしたときよりも、コードを構造化する方法について考える時間が大幅に短縮されました。

このアプローチに慣用的なGoコードを進化させる可能性があると思われる場合は、このtry()提案を検討する場合を含め、エラー処理を実装する際にそれを考慮に入れてください。

_「すべての人のためではない」_正当化

Goチームからの重要な回答の1つは、_「繰り返しになりますが、この提案はすべてのエラー処理状況を解決しようとするものではありません。」_
そして、それはガバナンスの観点から、おそらく最も厄介な懸念です。

この新しい複雑な言語の変更により、誰もが新しい概念を学ぶ必要があり、本当に多くのユースケースに対応できるでしょうか。

そして、コアチームの同じ正当化メンバーがコミュニティからの多数の機能要求を拒否したのではないでしょうか？ 以下は、約2年前に提出された機能リクエストへの典型的な応答でGoチームのメンバーが行ったコメントからの直接の引用です_（この議論はできないはずなので、私は人や特定の機能リクエストに名前を付けていません人々が代わりに言語について）：_

_ "新しい言語機能には説得力のあるユースケースが必要です。すべての言語機能が役立つか、誰も提案しません。問題は、言語を複雑にし、すべての人に新しい概念を学ぶことを要求するのに十分役立つかどうかです。説得力のある使用法は何ですか。ここでの事例？人々はこれらをどのように使用しますか？たとえば、人々は...できることを期待しますか？もしそうなら、どのようにそれを行いますか？この提案はあなたに許可する以上のことをしますか...？ "_
—Goチームのコアメンバー

率直に言って、私がそれらの反応を見たとき、私は2つの感情のうちの1つを感じました：

1. それが私が同意する機能であるかどうかの憤慨、または
2. それが私が同意しない機能であるならば、高揚感。

しかし、どちらの場合でも、私の気持ちは無関係でした。 Goが言語である理由の一部は、私たちの多くが開発することを選択する理由の一部は、言語の純粋さを嫉妬深く守るためであることを理解し、同意します。

そして、それがこの提案が私を悩ませている理由です。なぜなら、Goコアチームは、Goコミュニティがこれまで許容できないような難解な機能を独断的に望んでいる人と同じレベルでこの提案を掘り下げているようだからです。

_（そして、チームがメッセンジャーを撃って、これを、Goが私たち全員にとって最高であり続けることを望んでいる誰かからの建設的な批判として受け取らないことを心から願っています。コアチーム。）_

説得力のある一連の実際のユースケースがコミュニティで生成されたすべての機能提案の基準である場合、それは_すべての_機能提案の基準でもあるべきではありませんか？

try（）のネスト

これもいくつかでカバーされましたが、 try()と三項演算子の継続的な要求を比較したいと思います。 約18か月前の別のGoチームメンバーのコメントからの引用：

_ "「大規模なプログラミング」（長期間にわたる大規模なチームによる大規模なコードベース）の場合、コードは記述されるよりもはるかに頻繁に読み取られるため、書き込み可能性ではなく、可読性を最適化します。" _

三項演算子を追加しない理由の1つは、ネストされていると読みにくい、または誤読しやすいことです。 それでも、 try(try(try(to()).parse().this)).easily())のようなネストされたtry()ステートメントについても同じことが言えます。

三項演算子に反対する追加の理由は、それらが_ "式" _であり、ネストされた式が複雑さを増す可能性があるという引数があることです。 しかし、 try()もネスト可能な式を作成しませんか？

ここで誰かが_「[ネストされたtry() s]のような例は非現実的だと思います」_と言いました。そのステートメントは異議を唱えられませんでした。

しかし、開発者がtry()をネストしないという仮定を人々が受け入れる場合、人々が_「深くネストされた三項演算子は非現実的だと思う」と言うときに、なぜ同じ違いが三項演算子に与えられないのですか？

この点の結論として、三項演算子に対する議論が本当に有効である場合、それらもこのtry()提案に対する有効な議論と見なされるべきだと思います。

要約すれば

これを書いている時点で、 58%の反対票は42%の賛成票になっています。 これだけで、これがこの問題についての計画に戻る時が来たという提案を十分に分割していることを示すのに十分であると思います。

fwiw

PSそれをもっと冗談で言うと、私たちはヨーダの言い換えられた知恵に従うべきだと思います：

_ " try()はありません。 do()のみです。" _

@ianlancetaylor

@beoranおそらく、ジェネリックスとエラー処理の間の関係を拡張することができます。

@beoranについては話していませんが、数分前の私のコメントでは、ジェネリックス_（および可変個引数の戻りパラメーター）_があれば、独自のtry()を作成できることがわかります。

ただし、ここでジェネリックについて上で述べたことを繰り返します。

_ "ジェネリックスのユースケースは、Javaなどのジェネリックスの紛らわしいセマンティクスと構文サラダを追加するのではなく、ジェネリックスのユースケースに対処するための組み込みを追加することによって削減する必要があると思います。）" _

@ianlancetaylor

あなたの質問に対する答えを定式化しようとしたとき、私はGoにtry関数をそのまま実装しようとしましたが、嬉しいことに、実際には非常によく似たものをエミュレートすることがすでに可能です。

func try(v interface{}, err error) interface{} {
   if err != nil { 
     panic(err)
   }
   return v
}

使用方法はこちらをご覧ください：https： //play.golang.org/p/Kq9Q0hZHlXL

このアプローチの欠点は次のとおりです。

1. 遅延レスキューが必要ですが、この提案のようにtryを使用すると、適切なエラー処理を実行する場合に遅延ハンドラーも必要になります。 ですから、これは深刻なマイナス面ではないと思います。 Goに何らかのsuper(arg1, ..., argn)が組み込まれていると、呼び出しスタックの1レベル上の呼び出し元の呼び出し元が、指定された引数arg1、... argnで返され、一種のスーパーリターンが発生する場合はさらに良いでしょう。あなたがそうするなら。
2. 私が実装したこのtryは、単一の結果とエラーを返す関数でのみ機能します。
3. 返されたemtpyインターフェイスの結果をassertと入力する必要があります。

十分に強力なジェネリックは、問題2と3を解決でき、1つだけを残して、 super()を追加することで解決できます。 これらの2つの機能を使用すると、次のようになります。

func (T ... interface{})try(T, err error) super {
   if err != nil { 
      super(err)
   }
  super(T...)
}

そして、延期された救助はもう必要ありません。 この利点は、ジェネリックがGoに追加されていない場合でも利用できます。

実際、super（）ビルトインのこのアイデアは非常に強力で興味深いので、個別に提案を投稿するかもしれません。

@beoran別の提案で似たようなことについて話したかったので含めなかったスーパー部分を除いて、ユーザーランドでのtry()の実装に関して、まったく同じ制約に独立して到達したことを確認してください。 :-)

私はこの提案が好きですが、 defer try(...)とgo try(...)が許可されていないことを明示的に指定しなければならなかったという事実から、何かが正しくないと思いました。直交性は優れた設計ガイドです。 さらに読んで、次のようなものを見ることについて
x = try(foo(...)) y = try(bar(...))
tryはコンテキストである必要があるのではないかと思います！ 検討：
try ( x = foo(...) y = bar(...) )
ここで、 foo()とbar()は2つの値を返し、2番目はerrorです。 セマンティクスを試すことは、無視されるのではなく、返されたエラー値が省略される（レシーバーなし） tryブロック内の呼び出しにのみ関係します（レシーバーは_です）。 fooとbarの呼び出しの間にあるエラーを処理することもできます。

概要：
a） goとdeferのtryを許可しないという問題は、構文によって解消されます。
b）複数の機能のエラー処理を除外することができます。
c）その魔法の性質は、関数呼び出しとしてよりも特別な構文としてよりよく表現されます。

tryがコンテキストである場合、特に回避しようとしているtry / catchブロックを作成しました（そして正当な理由で）

キャッチはありません。 現在の提案が持っているときとまったく同じコードが生成されます
x = try(foo(...)) y = try(bar(...))
これは単なる異なる構文であり、セマンティクスではありません。
`` ``

それにはまだいくつかの欠点がありますが、私はそれについて私がすべきではなかったいくつかの仮定をしたと思います。

fooまたはbarがエラーを返さない場合、それらをtryコンテキストにも配置できますか？ そうでない場合は、エラー関数と非エラー関数を切り替えるのはちょっと醜いようです。可能な場合は、古い言語のtryブロックの問題にフォールバックします。

2つ目は、通常、 keyword ( ... )構文は、各行にキーワードのプレフィックスを付けることを意味します。 したがって、import、var、constなどの場合：各行はキーワードで始まります。 その規則に例外を設けることは良い決断ではないようです

関数を使用する代わりに、特別な識別子を使用する方が慣用的でしょうか？

値を無視する空白の識別子_がすでにあります。
#のようなものを使用できます。これは、エラー型の最後の戻り値を持つ関数でのみ使用できます。

func foo() (error) {
    f, # := os.Open()
    defer f.Close()
    _, # = f.WriteString("foo")
    return nil
}

エラーが#に割り当てられると、関数はエラーを受信するとすぐに戻ります。 他の変数に関しては、それらの値は次のようになります。

• それらがゼロ値と名付けられていない場合
• それ以外の場合は、名前付き変数に割り当てられた値

@deanveloper 、 tryブロックのセマンティクスは、エラー値を返し、エラー値が割り当てられていない関数にのみ関係します。 したがって、現在の提案の最後の例は、次のように書くこともできます。
try(x = foo(...)) try(y = bar(...))
両方のステートメントを同じブロック内に配置することは、繰り返されるimport 、 const 、およびvarステートメントに対して行うことと似ています。

今あなたが持っているなら、例えば
try( x = foo(...)) go zee(...) defer fum() y = bar(...) )
これは書くのと同じです
try(x = foo(...)) go zee(...) defer fum() try(y = bar(...))
1つのtryブロックでそれらすべてを除外すると、ビジー状態が少なくなります。

検討
try(x = foo())
foo（）がエラー値を返さない場合、これは次のようになります。
x = foo()

検討
try(f, _ := os.open(filename))
返されたエラー値は無視されるため、これは
f, _ := os.open(filename)

検討
try(f, err := os.open(filename))
返されたエラー値は無視されないため、これは次のようになります。
f, err := os.open(filename) if err != nil { return ..., err }
現在提案で指定されているとおり。

また、ネストされた試行をうまく整理します！

上記の代替案へのリンクは次のとおりです。

• https://github.com/golang/go/issues/32473

try()と同じユースケースに対処するために、2つの小さいが汎用言語機能を追加する必要があります

1. 代入ステートメントでfunc / closureを呼び出す機能。
2. 複数のレベルでbreak 、 continue 、またはreturnを実行する機能。

この2つの機能を使用すると、それらは_「魔法」_ではなくなり、それらを使用すると、理解しやすく、私たちがよく知っている慣用的なGoコードとより一致するGoコードが生成されると思います。

私は提案を読みました、そして、試みがどこに行くのか本当に好きです。

試行がどれほど普及するかを考えると、それをよりデフォルトの動作にすることで、処理が容易になるのではないかと思います。

マップを検討してください。 これは有効です：

v := m[key]

これは次のとおりです。

v, ok := m[key]

tryが提案するのとまったく同じ方法でエラーを処理し、組み込みを削除するとどうなりますか。 したがって、次のように始めた場合：

v, err := fn()

書く代わりに：

v := try(fn())

代わりに次のように書くことができます。

v := fn()

err値がキャプチャされない場合、tryとまったく同じように処理されます。 慣れるのに少し時間がかかりますが、 v, ok := m[key]とv, ok := x.(string)に非常に似ているように感じます。 基本的に、未処理のエラーが発生すると、関数が返され、エラー値が設定されます。

設計ドキュメントの結論と実装要件に戻るには：

•言語構文は保持され、新しいキーワードは導入されません
•それはtryのような構文糖衣であり続け、うまくいけば説明が簡単です。
•新しい構文は必要ありません
•完全な下位互換性が必要です。

主な違いは、組み込みがシンタックスシュガーをトリガーするのではなく、errフィールドがないため、これはtryとほぼ同じ実装要件になると思います。

したがって、提案のCopyFileの例とdefer fmt.HandleErrorf(&err, "copy %s %s", src, dst)を使用すると、次のようになります。

func CopyFile(src, dst string) (err error) {
        defer fmt.HandleErrorf(&err, "copy %s %s", src, dst)

        r := os.Open(src)
        defer r.Close()

        w := os.Create(dst)
        defer func() {
                err := w.Close()
                if err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        io.Copy(w, r)
        w.Close()
        return nil
}

@savaki私はこれが好きで、Goがデフォルトで常にエラーを処理することでエラー処理を反転させ、プログラマーにそうしないタイミングを指定させる（エラーを変数にキャプチャすることによって）ようにするために何が必要かを考えていましたが、識別子を使用すると、すべてのリターンポイントを確認できないため、コードを追跡するのが難しくなります。 エラーを別の方法で返す可能性のある関数に名前を付けるための規則である可能性があります（パブリック識別子の大文字化など）。 関数がエラーを返した場合は、常に?で終わる必要があります。 そうすれば、Goは常に暗黙的にエラーを処理し、tryと同じように呼び出し元の関数に自動的に返すことができます。 これは、tryの代わりに?識別子を使用することを提案するいくつかの提案と非常に似ていますが、重要な違いは、ここで?が関数名の一部であり、追加の識別子ではないことです。 実際、最後の戻り値としてerrorを返した関数は、接尾辞?がないと、コンパイルすらできません。 もちろん?は任意であり、意図をより明確にする他のものに置き換えることができます。 operation?()はtry(someFunc())をラップするのと同じですが、 ?は関数名の一部であり、関数が大文字と同じようにエラーを返すことができることを示すことが唯一の目的です。変数の最初の文字。

これは表面的にはtryを?に置き換えることを求める他の提案と非常に似ていますが、重要な違いは、エラー処理を暗黙的（自動）にし、代わりに無視（またはラッピング）エラーを明示的にすることです。とにかく一種のベストプラクティス。 もちろん、これに関する最も明白な問題は、下位互換性がないことであり、さらに多くの問題があると確信しています。

そうは言っても、Goがデフォルト/暗黙のケースを自動化して処理中にエラーを発生させ、プログラマーに処理を無視/オーバーライドするための追加のコードを少し記述させる方法を知りたいと思います。 私が考える課題は、この場合、すべてのリターンポイントを明確にする方法です。これがないと、プログラムのフローでは明確にならないため、エラーはどこからでも発生する可能性があるという意味で、例外のようになります。 視覚的なインジケータでエラーを暗黙的にすることは、 tryを実装してerrcheckをコンパイラの失敗にすることと同じであると言えます。

古い関数のデコレータを使用してC ++例外のようなことを行うことができますか？

func some_old_test() (int, error){
    return 0, errors.New("err1")
}
func some_new_test() (int){
        if true {
             return 1
        }
    throw errors.New("err2")
}
func throw_res(int, e error) int {
    if e != nil {
        throw e
    }
    return int
}
func main() {
    fmt.Println("Hello, playground")
    try{
        i := throw_res(some_old_test())
        fmt.Println("i=", i + some_new_test())
    } catch(err io.Error) {
        return err
    } catch(err error) {
        fmt.Println("unknown err", err)
    }
}

@owaisセマンティクスはtryとまったく同じだと思っていたので、少なくともerrタイプを宣言する必要があります。 したがって、次のように始めた場合：

func foo() error {
  _, err := fn() 
  if err != nil {
    return err
  }

  return nil
} 

私がtryの提案を理解している場合は、これを行うだけです。

func foo() error {
  _  := fn() 
  return nil
} 

コンパイルされません。 素晴らしい特典の1つは、コンパイルに何が欠けているかをユーザーに伝える機会を与えることです。 暗黙のエラー処理を使用するには、エラー戻りタイプにerrという名前を付ける必要があるという効果があります。

これでうまくいくでしょう：

func foo() (err error) {
  _  := fn() 
  return nil
} 

変数に割り当てられていないエラーの場合を処理しないのはなぜですか。

• 名前付きリターンの必要性を排除し、コンパイラーはこれをすべて独自に行うことができます。
• コンテキストを追加できます。
• 一般的なユースケースを処理します。
• 下位互換性
• 延期、ループ、またはスイッチと奇妙に相互作用しません。

if err！= nilの場合の暗黙の戻り値。コンパイラーは、必要に応じてプログラマーがアクセスできない場合に、戻り値のローカル変数名を生成できます。
個人的には、コードの可読性の観点から、この特定のケースは嫌いです

f := os.Open("foo.txt")

明示的なリターンを好み、コードは書かれたマントラよりも多く読まれます

f := os.Open("foo.txt") else return

興味深いことに、両方のフォームを受け入れて、gofmtにelseリターンを自動的に追加させることができます。

コンテキストの追加、変数のローカル命名。 コンテキストを追加したいので、returnは明示的になります。

f := os.Open("foo.txt") else err {
  return errors.Wrap(err, "some context")
}

複数の戻り値を持つコンテキストの追加

f := os.Open("foo.txt") else err {
  return i, j, errors.Wrap(err, "some context")
}

ネストされた関数では、外部関数がすべての結果を同じ順序で処理する必要があります
最終エラーを差し引いた。

bits := ioutil.ReadAll(os.Open("foo")) else err {
  // either error ends up here.
  return i, j, errors.Wrap(err, "some context")
}

関数にエラーの戻り値がないため、コンパイラがコンパイルを拒否します

func foo(s string) int {
   i := strconv.Atoi(s) // cannot implicitly return error due to missing error return value for foo.
   return i * 2
}

エラーは明示的に無視されるため、問題なくコンパイルされます。

func foo(s string) int {
   i, _ := strconv.Atoi(s)
   return i * 2
} 

コンパイラは幸せです。 割り当てや接尾辞が発生しないため、現在のようにエラーは無視されます。

func foo() error {
  return errors.New("whoops")
}

func bar() {
  foo()
}

ループ内で続行を使用できます。

for _, s := range []string{"1","2","3","4","5","6"} {
  i := strconv.Atoi(s) else continue
}

編集： ;をelseに置き換えました

@savaki私はあなたの元のコメントを理解したと思います。デフォルトでエラーを処理するGoのアイデアは好きですが、構文の変更を追加しないと実行可能ではないと思います。そうすると、現在の提案と非常によく似たものになります。

あなたが提案することの最大の欠点は、現在のif err != nil {return err}やこの提案で導入されたtry関数とは異なり、関数が戻ることができるすべてのポイントを公開しないことです。 内部ではまったく同じように機能しますが、視覚的にはコードは非常に異なって見えます。 コードを読み取るときに、どの関数呼び出しがエラーを返す可能性があるかを知る方法はありません。 それは、例外IMOよりも悪い経験になるでしょう。

コンパイラがエラーを返す可能性のある関数にセマンティック規則を強制した場合、エラー処理が暗黙的に行われる可能性があります。 彼らは特定のフレーズや文字で開始または終了する必要があるように。 それはすべてのリターンポイントを非常に明白にし、手動のエラー処理よりも優れていると思いますが、無視されているエラーを見つけたときに負荷を叫ぶリントチェックがすでにあることを考えると、どれほど優れているかはわかりません。 可能性のあるエラーを返す可能性があるかどうかに応じて、コンパイラーが関数に特定の方法で名前を付けることができるかどうかを確認することは非常に興味深いでしょう。

このアプローチの主な欠点は、エラー結果パラメーターに名前を付ける必要があることです。これにより、APIの品質が低下する可能性があります（ただし、このテーマに関するFAQを参照してください）。 このスタイルが確立されれば、私たちはそれに慣れるだろうと信じています。

このようなものが以前に提案されたかどうかはわかりませんが、ここまたは提案で見つけることができません。 現在の関数のエラー戻り値へのポインタを返す別の組み込み関数を検討しましたか？
例えば：

func example() error {
        var err *error = funcerror() // always return a non-nil pointer
        fmt.Print(*err) // always nil if the return parameters are not named and not in a defer

        defer func() {
                err := funcerror()
                fmt.Print(*err) // "x"
        }

        return errors.New("x")
}

func exampleNamed() (err error) {
        funcErr := funcerror()
        fmt.Print(*funcErr) // "nil"

        err = errors.New("x")
        fmt.Print(*funcErr) // "x", named return parameter is reflected even before return is called

        *funcErr = errors.New("y")
        fmt.Print(err) // "y", unfortunate side effect?

        defer func() {
                funcErr := funcerror()
                fmt.Print(*funcErr) // "z"
                fmt.Print(err) // "z"
        }

        return errors.New("z")
}

tryでの使用法：

func CopyFile(src, dst string) (error) {
        defer func() {
                err := funcerror()
                if *err != nil {
                        *err = fmt.Errorf("copy %s %s: %v", src, dst, err)
                }
        }()
        // one liner alternative
        // defer fmt.HandleErrorf(funcerror(), "copy %s %s", src, dst)

        r := try(os.Open(src))
        defer r.Close()

        w := try(os.Create(dst))
        defer func() {
                w.Close()
                err := funcerror()
                if *err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        try(io.Copy(w, r))
        try(w.Close())
        return nil
}

あるいは、funcerror（名前は進行中の作業です：D）は、defer内で呼び出されない場合、nilを返す可能性があります。

もう1つの方法は、funcerrorが「Errorer」インターフェースを返して読み取り専用にすることです。

type interface Errorer() {
        Error() error
}

@savaki私は実際、 try()を省略して、マップや型アサーションをテストするようなものにするというあなたの提案が好きです。 それははるかに感じます_ "Go-like。" _

ただし、まだ1つの明白な問題があります。それは、このアプローチを使用するすべてのエラーがreturnをトリガーし、関数を終了することを前提としているということです。 現在のforからbreakを発行するか、現在のforに対してcontinueを発行することは想定されていません。

初期のreturnは、メスが多くの場合より良い選択である場合、大ハンマーです。

したがって、 breakとcontinueは有効なエラー処理戦略として許可されるべきであり、現在、あなたの提案はreturnのみを想定していますが、 try()はそれを想定しているか、エラーを呼び出していますそれ自体がreturnのみを実行でき、 breakまたはcontinueは実行できないハンドラー。

savakiのように見えますが、私は似たような考えを持っていました。必要に応じて、エラーを処理するためのブロックセマンティクスを追加しました。 たとえば、comtextを追加したり、短絡させたいループの場合など

@mikeschinkelは私の拡張機能を参照してください、彼と私は同様のアイデアを持っていました私はオプションのブロックステートメントでそれを拡張しました

@ james-ローレンス

@mikesckinkelは私の拡張機能を参照してください、彼と私は同様のアイデアを持っていました私はオプションのブロックステートメントでそれを拡張しました

あなたの例を取る：

f := os.Open("foo.txt"); err {
  return errors.Wrap(err, "some context")
}

これは、今日私たちが行っていることと比較されます。

f,err := os.Open("foo.txt"); 
if err != nil {
  return errors.Wrap(err, "some context")
}

私には間違いなく好ましいです。 いくつかの問題があることを除いて：

1. errは_ "魔法のように" _宣言されているようです。 魔法は最小限に抑えるべきですよね？ それでそれを宣言しましょう：

f, err := os.Open("foo.txt"); err {
  return errors.Wrap(err, "some context")
}

1. ただし、Goはnil値をfalseとして解釈せず、ポインター値をtrueとして解釈しないため、それでも機能しません。したがって、次のようにする必要があります。

f, err := os.Open("foo.txt"); err != nil {
  return errors.Wrap(err, "some context")
}

そして、それが機能することで、1行に同じくらい多くの作業と多くの構文があるように感じ始めるので、明確にするために古い方法を継続する可能性があります。

しかし、Goが2つのビルトインを追加した場合はどうなるでしょうか。 iserror()とerror() ？ 次に、これを行うことができますが、これは私にとってそれほど悪くはありません。

f := os.Open("foo.txt"); iserror() {
  return errors.Wrap(error(), "some context")
}

またはより良い_（のようなもの）：_

f := os.Open("foo.txt"); iserror() {
  return error().Extend("some context")
}

あなたや他の人はどう思いますか？

余談ですが、ユーザー名のスペルを確認してください。 とにかく注意を払っていなかったら、あなたの言及は通知されなかっただろう...

@mikeschinkelは私の電話にあった名前について申し訳ありませんが、githubは自動提案していませんでした。

エラーは「魔法のように」宣言されているようです。 魔法は最小限に抑えるべきですよね？ それでそれを宣言しましょう：

まあ、リターンを自動的に挿入するというアイデア全体は魔法です。 これは、この提案全体で起こっている最も魔法のようなことではありません。 さらに、エラーが宣言されたと主張します。 スコープブロックのコンテキスト内の最後で、ifステートメントを使用して通常取得するすべての優れた機能を維持しながら、親スコープを汚染しないようにします。

私は一般的に、エラーパッケージへの今後の追加によるgoのエラー処理にかなり満足しています。 この提案には、非常に役立つものは何もありません。 私たちがそれをやろうと決心しているなら、私はゴランに最も自然なフィット感を提供しようとしています。

_「リターンを自動的に挿入するというアイデア全体は魔法のようなものです。」_

そこにいる私からは何の議論もありません。

_「これは、この提案全体で起こっている最も魔法のようなことではありません。」_

私は_「すべての魔法は問題がある」と主張しようとしていたと思います。

_ "さらに、エラーが宣言されたと主張します。スコープブロックのコンテキスト内の最後に..." _

それで、私がそれをerr2と呼びたいのなら、これもうまくいくでしょうか？

f := os.Open("foo.txt"); err2 {
  return errors.Wrap(err, "some context")
}

したがって、セミコロンの後のerr / err2の特殊なケースの処理も提案していると思います。つまり、 nil nilはないと想定されます。地図をチェックするときのようにbool $の代わりにnil ？

if _,ok := m[a]; !ok {
   print("there is no 'a' in 'm'")
}

私は一般的に、エラーパッケージへの今後の追加によるgoのエラー処理にかなり満足しています。

breakおよびcontinue _（ただし、 returnはない）と組み合わせると、エラー処理にも満足しています。

現状では、このtry()の提案は、役立つというよりも有害であると考えており、提案されたとおりにこの実装以外の何物も見たくありません。 #jmtcw。

@beoran @mikeschinkel以前、このバージョンのtryは、制御フローが変更されるため、ジェネリックを使用して実装できないことを提案しました。 私が正しく読んでいるなら、あなたは両方とも、ジェネリックを使用してpanicを呼び出すことにより、 tryを実装できることを示唆しています。 しかし、このバージョンのtry 、非常に明示的にpanicはありません。 したがって、ジェネリックを使用してこのバージョンのtryを実装することはできません。

はい、ジェネリック（https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.mdのデザインドラフトにあるものよりもはるかに強力なジェネリックのバージョン）を使用して関数を作成できます。エラーでパニックになります。 しかし、エラーでパニックになることは、Goプログラマーが今日書いているようなエラー処理ではなく、私には良い考えではないようです。

@mikeschinkelの特別な処理では、エラーが発生した場合にのみブロックが実行されます。
`` `
f：= os.Open（ 'foo'）; err {return err} //ここでは、errは常に非nilになります。

@ianlancetaylor

_ "はい、ジェネリックスを使用できます...しかし、エラーでパニックになることは、Goプログラマーが今日書いているようなエラー処理ではなく、私には良い考えではないようです。" _

私は実際にこれについてあなたに強く同意します、それであなたは私のコメントの意図を誤解したようです。 私は、Goチームがpanic()を使用するエラー処理を実装することをまったく示唆していませんでした—もちろんそうではありません。

代わりに、私は他の問題に関する過去のコメントの多くから実際にあなたの先導に従うことを試み、代わりにユーザーランドで可能であるため、絶対に必要ではないGoへの変更を避けることを提案しました。 したがって、_if_ジェネリックスは、 panic()を活用することで、 try()を実際に自分で実装できるようにしたいという_then_の人々に向けられました。 これは、チームがGoに追加して文書化する必要のある機能が1つ少なくなります。

私がしていなかったこと、そしておそらくそれは明確ではなかったのですが、人々が実際にpanic()を使用して$＃ try() ＃$を実装することを提唱していました。ジェネリック。

それは明確ですか？

私にとってpanicと呼ぶのは、それがどのように行われたとしても、 tryのこの提案とはまったく異なります。 ですから、私はあなたが言っていることを理解していると思いますが、それらが同等であることに同意しません。 パニックになるバージョンのtryを実装するのに十分強力なジェネリックがあったとしても、この提案で提示されたバージョンのtryに対する合理的な欲求はまだあると思います。

@ianlancetaylor確認済み。 繰り返しになりますが、 try()を追加する方法を見つけるのではなく、追加する必要がない理由を探していました。 上で述べたように、ここで提案されているtry()を使用するよりも、エラー処理に新しいものはありません。

私は個人的に、純粋に視覚的な側面に基づいて、これよりも以前のcheckの提案が好きでした。 checkはこのtry()と同じパワーを持っていましたが、 bar(check foo())はbar(try(foo()))よりも読みやすくなっています（括弧を数えるのに1秒必要でした！）。

さらに重要なことに、 handle / checkについての私の主な不満は、個々の小切手をさまざまな方法で折り返すことができないということでした。そして今、このtry()の提案にも同じ欠陥があります。トリッキーなめったに使用されない初心者を呼び出す間-延期と名前付きリターンの紛らわしい機能。 そして、少なくともhandleでは、スコープを使用してハンドルブロックを定義するオプションがありましたが、 deferでもそれは不可能です。

私に関する限り、この提案は、あらゆる点で以前のhandle / checkの提案に負けています。

エラー処理にdefersを使用する場合のもう1つの懸念事項があります。

tryは、関数からの制御された/意図された終了です。 関数からの制御されていない/意図しない終了を含め、延期は常に実行されます。 その不一致は混乱を引き起こす可能性があります。 これが架空のシナリオです。

func someHTTPHandlerGuts() (err error) {
  defer func() {
    recordMetric("db call failed")
    return fmt.HandleErrorf("db unavailable: %v", err)
  }()
  data := try(makeDBCall)
  // some code that panics due to a bug
  return nil
}

net / httpがパニックから回復することを思い出してください。そして、パニックの周りの本番環境の問題をデバッグすることを想像してください。 インストルメンテーションを見ると、 recordMetric呼び出しから、db呼び出しの失敗が急増していることがわかります。 これは、次の行のパニックである本当の問題を覆い隠す可能性があります。

これが実際にどれほど深刻な懸念であるかはわかりませんが、（悲しいことに）延期がエラー処理の理想的なメカニズムではないと考えるもう1つの理由です。

提起された懸念のいくつかに役立つ可能性のある変更を次に示します。 return $ではなくgotoのようにtryを扱います。 聞いてください。 :)

tryは、代わりに次の構文糖衣になります。

t1, … tn, te := f()  // t1, … tn, te are local (invisible) temporaries
if te != nil {
        err = te   // assign te to the error result parameter
        goto error // goto "error" label
}
x1, … xn = t1, … tn  // assignment only if there was no error

利点：

• エラーを装飾するためにdeferは必要ありません。 （ただし、名前付きの返品は引き続き必要です。）
• error:ラベルの存在は、関数のどこかにtryがあることを視覚的に示しています。

これは、関数としてのハンドラーの問題を回避するハンドラーを追加するためのメカニズムも提供します。ハンドラーとしてラベルを使用します。 try(fn(), wrap)は、 goto error $ではなくgoto wrapになります。 コンパイラは、 wrap:が関数に存在することを確認できます。 ハンドラーがあるとデバッグにも役立つことに注意してください。ハンドラーを追加/変更して、デバッグパスを提供できます。

サンプルコード：

func CopyFile(src, dst string) (err error) {
    r := try(os.Open(src))
    defer r.Close()

    w := try(os.Create(dst))
    defer func() {
        w.Close()
        if err != nil {
            os.Remove(dst) // only if a “try” fails
        }
    }()

    try(io.Copy(w, r), copyfail)
    try(w.Close())
    return nil

error:
    return fmt.Errorf("copy %s %s: %v", src, dst, err)

copyfail:
    recordMetric("copy failure") // count incidents of this failure
    return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

他のコメント：

• tryのターゲットとして使用されるラベルの前に、終了ステートメントを付ける必要がある場合があります。 実際には、これは関数の最後にそれらを強制し、いくつかのスパゲッティコードを防ぐことができます。 一方で、それはいくつかの合理的で有用な使用を妨げるかもしれません。
• tryを使用してループを作成できます。 これは「痛いならやらない」という旗印に該当すると思いますが、よくわかりません。
• これには、 https：//github.com/golang/go/issues/26058を修正する必要があります。

クレジット：このアイデアの変形は、昨年GopherConで@griesemerが直接提案したものだと思います。

@josharian panicとの相互作用について考えることはここで重要であり、あなたがそれを提起してくれてうれしいですが、あなたの例は私には奇妙に思えます。 次のコードでは、deferが常に"db call failed"メトリックを記録することは私には意味がありません。 someHTTPHandlerGutsが成功し、 nilを返す場合、これは誤ったメトリックになります。 deferは、エラーやパニックの場合だけでなく、すべての終了の場合に実行されるため、パニックがなくてもコードは間違っているように見えます。

func someHTTPHandlerGuts() (err error) {
  defer func() {
    recordMetric("db call failed")
    return fmt.HandleErrorf("db unavailable: %v", err)
  }()
  data := try(makeDBCall)
  // some code that panics due to a bug
  return nil
}

@josharianはい、これは多かれ少なかれ昨年説明したバージョンです（ただし、 try checkを使用しました）。 errorラベルに到達したら、関数本体の残りの部分に「戻る」ことができないことが重要だと思います。 これにより、 gotoがある程度「構造化」されていることが保証されます（スパゲッティコードは使用できません）。 提起された懸念の1つは、エラーハンドラー（ error: ）ラベルが常に関数の最後に来ることでした（そうでない場合は、なんらかの方法でジャンプする必要があります）。 個人的には、（最後に）邪魔にならないエラー処理コードが好きですが、他の人はそれが最初から見えるはずだと感じました。

@mikeshenkelループから戻るのは、マイナスではなくプラスだと思います。 私の推測では、開発者はループの内容を処理するために別の関数を使用するか、現在のようにerrを明示的に使用するように促されます。 これらは両方とも私には良い結果のように思えます。

私のPOVからは、このtry構文は、使用する必要がないと感じているのと同じように、すべてのユースケースを処理する必要があるとは感じていません。

V、ok：= m [key]

地図からの読み取りからのフォーム

handle / checkプロポーザルを簡略化された形式で復活させることにより、gotoラベルがハンドラーを関数の最後に強制することを回避できます。 handle err { ... }構文を使用したが、ハンドラーをチェーンさせなかった場合はどうなりますか。代わりに、最後の1つだけが使用されます。 これは、その提案を大幅に簡素化し、処理を使用場所に近づけることを除いて、gotoのアイデアと非常によく似ています。

func CopyFile(src, dst string) (err error) {
    handle err {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    r := check os.Open(src)
    defer r.Close()

    w := check os.Create(dst)
    defer func() {
        w.Close()
        if err != nil {
            os.Remove(dst) // only if a “check” fails
        }
    }()

    {
        // handlers are scoped, after this scope the original handle is used again.
        // as an alternative, we could have repeated the first handle after the io.Copy,
        // or come up with a syntax to name the handlers, though that's often not useful.
        handle err {
            recordMetric("copy failure") // count incidents of this failure
            return fmt.Errorf("copy %s %s: %v", src, dst, err)
        }
        check io.Copy(w, r)
    }
    check w.Close()
    return nil
}

ボーナスとして、これには、ハンドラーをチェーンさせるための将来のパスがあります。これは、既存のすべての用途に利益があるためです。

@josharian @griesemer名前付きハンドラー（チェック/ハンドルへの多くの応答が要求されました。定期的なテーマを参照）を導入する場合、 try(f(), err)よりも望ましい構文オプションがあります。

try.err f()
try?err f()
try#err f()

?err    f() // because 'try' is redundant
?return f() // no handler
?panic  f() // no handler

(?err f()).method()

f?err() // lead with function name, instead of error handling
f?err().method()

file, ?err := os.Open(...) // many check/handle responses also requested this style

Goについて私が最も気に入っていることの1つは、その構文が比較的句読点がなく、大きな問題なしに大声で読み上げることができることです。 Goが$#@!perlになるのは本当に嫌いだ。

私にとって、組み込み関数を「試す」こととチェーンを有効にすることには、2つの問題があります。

• これは、goの残りの制御フロー（たとえば、for / if / return / etcキーワード）と矛盾しています。
• コードが読みにくくなります。

かっこなしでステートメントにしたいと思います。 提案の例では複数行が必要になりますが、読みやすくなります（つまり、個々の「試行」インスタンスを見逃しにくくなります）。 はい、それは外部パーサーを壊しますが、私は一貫性を維持することを好みます。

三項演算子は別の場所であり、何かがなく、より多くのキーストロークが必要ですが、同時に読みやすさ/保守性が向上します。 このより制限された形式で「試行」を追加すると、表現力と読みやすさ、IMOのバランスが改善されます。

FWIW、 panicは制御フローに影響を与え、親子関係がありますが、 goとdeferもフローに影響を与え、影響を与えません。 tryはdeferに似ていると思う傾向があります。これは、異常なフロー操作であり、ワンライナーを思いとどまらせたいので、 try (try os.Open(file)).Read(buf)を実行しにくくすることは良いことです。とにかく、でも何でも。 どちらでも構いません。

誰もが最終的なエラー戻り変数の暗黙の名前を嫌うだろうという提案： $err 。 try() IMOよりも優れています。 :-)

@griesemer

_ "個人的には、（最後に）邪魔にならないエラー処理コードが好きです" _

+1！

エラーが発生する前に実装されたエラー処理は、エラーが発生した後に実装されたエラー処理よりも推論がはるかに難しいことがわかりました。 精神的に戻ってロジックフローに従うように強制する必要があるのは、1980年にGOTOでBasicを書いているような気がします。

もう一度例としてCopyFile()を使用して、エラーを処理するさらに別の潜在的な方法を提案しましょう。

func CopyFile(src, dst string) (err error) {

    r := os.Open(src)
    defer r.Close()

    w := os.Create(dst)
    defer w.Close()

    io.Copy(w, r)
    w.Close()

    for err := error {
        switch err.Source() {
        case w.Close:
            os.Remove(dst) // only if a “try” fails
            fallthrough
        case os.Open, os.Create, io.Copy:
            err = fmt.Errorf("copy %s %s: %v", src, dst, err)
        default:
            err = fmt.Errorf("an unexpected error occurred")
        }
    }

    return err
}

必要な言語の変更は次のとおりです。

1. for range{}と同様に、 for error{}構造を許可しますが、エラー時にのみ入力され、1回だけ実行されます。

2. <object>.Error() stringを実装する戻り値のキャプチャを省略できますが、同じfunc内にfor error{}構造が存在する場合に限ります。

3. funcが最後の戻り値で_ "error" _を返したときに、プログラム制御フローをfor error{}構造の最初の行にジャンプさせます。

4. _ "error" _ Goを返す場合、 <error>.Source()で取得できるはずのエラーを返した関数への参照を割り当てます。

_「エラー」_とは何ですか？

現在、_ "error" _は、 Error() stringを実装するオブジェクトとして定義されており、もちろんnilではありません。

ただし、RESTful APIの成功結果に必要な値を返すことができるように、成功した場合でもエラーを拡張する必要があることがよくあります。 したがって、Goチームは、 err!=nilが_ "エラー" _を意味すると自動的に想定しないでください。代わりに、エラーオブジェクトがIsError()を実装しているかどうか、およびIsError()がtrueを返すかどうかを確認してください。 nil以外の値が_ "エラー" _であると想定する前に

_（私は必ずしも標準ライブラリのコードについて話しているわけではありませんが、主に制御フローを選択して_ "エラー" _で分岐する場合。 err!=nilだけを見ると、私たちの内容は非常に制限されます。関数の戻り値に関して実行できます。）_

ところで、誰もが_ "エラー" _を同じ方法でテストできるようにするには、新しい組み込みのiserror()関数を追加することでおそらく最も簡単に実行できます。

type ErrorIser interface {
    IsError() bool
}
func iserror(err error) bool {
    if err == nil { 
        return false
    }
    if _,ok := err.(ErrorIser); !ok {
        return true
    }
    return err.IsError()
}

_ "エラー" _の非キャプチャを許可することの副次的な利点

func呼び出しからの最後の_ "error" _の非キャプチャを許可すると、後でリファクタリングして、最初はエラーを返す必要がなかったfuncからのエラーを返すことができることに注意してください。 また、この形式のエラー回復を使用し、 funcを呼び出す既存のコードを壊すことなく、このリファクタリングが可能になります。

私にとって、_「単純性を呼び出すためにエラーを返すか、エラー処理を放棄する必要がありますか？」という決定は、Goコードを書くときの私の最大の悩みの種の1つです。 上記の_ "エラー" _の非キャプチャを許可すると、その難問はほとんどなくなります。

私は実際にこのアイデアをGoトランスレータとして約半年前に実装しようとしました。 この機能をGo組み込みとして追加する必要があるかどうかについては強い意見はありませんが、経験を共有させてください（有用かどうかはわかりませんが）。

https://github.com/rhysd/trygo

拡張言語のTryGoを呼び出し、TryGo toGoトランスレータを実装しました。

翻訳者と一緒に、コード

func CreateFileInSubdir(subdir, filename string, content []byte) error {
    cwd := try(os.Getwd())

    try(os.Mkdir(filepath.Join(cwd, subdir)))

    p := filepath.Join(cwd, subdir, filename)
    f := try(os.Create(p))
    defer f.Close()

    try(f.Write(content))

    fmt.Println("Created:", p)
    return nil
}

に翻訳することができます

func CreateFileInSubdir(subdir, filename string, content []byte) error {
    cwd, _err0 := os.Getwd()
    if _err0 != nil {
        return _err0
    }

    if _err1 := os.Mkdir(filepath.Join(cwd, subdir)); _err1 != nil {
        return _err1
    }

    p := filepath.Join(cwd, subdir, filename)
    f, _err2 := os.Create(p)
    if _err2 != nil {
        return _err2
    }
    defer f.Close()

    if _, _err3 := f.Write(content); _err3 != nil {
        return _err3
    }

    fmt.Println("Created:", p)
    return nil
}

言語の制限のため、ジェネリックtry()呼び出しを実装できませんでした。 に制限されています

• 定義ステートメントのRHS
• 割り当てステートメントのRHS
• コールステートメント

しかし、私は私の小さなプロジェクトでこれを試すことができました。 私の経験は

• 基本的には正常に動作し、数行節約できます
• 名前付きの戻り値は、その関数の戻り値が割り当てとtry()特殊関数の両方によって決定されるため、実際にはerr使用できません。 とても混乱するような
• このtry()関数には、上記の「ラッピングエラー」機能がありませんでした。

_「これらは両方とも私には良い結果のようです。」_

ここで同意しないことに同意する必要があります。

_ "このtry構文（する必要はありません）はすべてのユースケースを処理します" _

そのミームはおそらく最も厄介です。 少なくとも、Goチーム/コミュニティが、広く適用できない過去の変更に対してどれほど抵抗力があるかを考えると。

ここでその正当化を認めるなら、広く適用できなかったために却下された過去の提案を再検討できないのはなぜですか？

そして、選択したエッジケースにのみ役立つGoの変更について議論できるようになりましたか？

私の推測では、この先例を設定しても、長期的には良い結果は得られません...

_ "@ mikeshenkel" _

PSスペルミスのため、最初はメッセージが表示されませんでした。 _（これは私を怒らせません。ユーザー名のつづりを間違えても通知されません...）_

tryをキーワードではなく組み込みにする動機付けとなる下位互換性への取り組みに感謝しますが、制御フローを変更できる頻繁に使用される関数（ panicとrecoverは非常にまれです）、私は疑問に思いました：オープンソースコードベースの識別子としてtryの頻度の大規模な分析を行った人はいますか？ 私は好奇心旺盛で懐疑的だったので、次の項目について予備調査を行いました。

• https://github.com/google/go-github
• https://github.com/cockroachdb/cockroach
• https://github.com/golang/net
• https://github.com/exercism/xgo
• https://github.com/GoogleCloudPlatform/kubernetes
• https://github.com/syncthing/syncthing
• https://github.com/mitchellh/packer
• https://github.com/drone/drone
• https://github.com/coreos/etcd
• https://github.com/docker/docker
• https://github.com/sjwhitworth/golearn
• https://github.com/bitly/nsq
• https://github.com/smartystreets/goconvey
• https://github.com/golang/tools
• https://github.com/coreos/fleet
• https://github.com/limetext/lime
• https://github.com/flynn/flynn
• https://github.com/dropbox/godropbox
• https://github.com/hashicorp/consul
• https://github.com/hashicorp/terraform

これらのリポジトリに存在するGoの11,108,770の重要な行全体で、識別子として使用されているtryのインスタンスは63個しかありませんでした。 もちろん、これらのコードベース（大きく、広く使用されており、それ自体が重要です）は、Goコードのごく一部にすぎず、さらに、プライベートコードベースを直接分析する方法はありませんが、確かにそうです。興味深い結果です。

さらに、 tryは、他のキーワードと同様に小文字であるため、パッケージのパブリックAPIで見つけることはできません。 キーワードの追加は、パッケージの内部にのみ影響します。

これはすべて、キーワードとしてtryの恩恵を受ける、私がミックスに投入したかったいくつかのアイデアの序文です。

以下の構造を提案します。

1）ハンドラーなし

// The existing proposal, but as a keyword rather than builtin.  When an error is 
// "caught", the function returns all zero values plus the error.  Nothing 
// particularly new here.
func doSomething() (int, error) {
    try SomeFunc()
    a, b := try AnotherFunc()

    // ...

    return 123, nil
}

2）ハンドラー

エラーハンドラーは、関数ではなくインライン化を目的とした単純なコードブロックであることに注意してください。 これについては、以下で詳しく説明します。

func doSomething() (int, error) {
    // Inline error handler
    a, b := try SomeFunc() else err {
        return 0, errors.Wrap(err, "error in doSomething:")
    }

    // Named error handlers
    handler logAndContinue err {
        log.Errorf("non-critical error: %v", err)
    }
    handler annotateAndReturn err {
        return 0, errors.Wrap(err, "error in doSomething:")
    }

    c, d := try SomeFunc() else logAndContinue
    e, f := try OtherFunc() else annotateAndReturn

    // ...

    return 123, nil
}

提案された制限：

• 関数呼び出しtryのみ可能です。 try errありません。
• ハンドラーを指定しない場合、右端の戻り値としてエラーを返す関数内からのみtryを指定できます。 tryのコンテキストに基づく動作に変更はありません。 パニックになることはありません（スレッドの前半で説明したように）。
• いかなる種類の「ハンドラーチェーン」もありません。 ハンドラーは単なるインライン化できないコードブロックです。

利点：

• try / else構文は、既存の「複合if」に簡単に脱糖することができます。
  go a, b := try SomeFunc() else err { return 0, errors.Wrap(err, "error in doSomething:") }
  になります
  go if a, b, err := SomeFunc(); err != nil { return 0, errors.Wrap(err, "error in doSomething:") }
  私の目には、複眼は非常に単純な理由で役立つよりも常に混乱しているように見えました。条件文は通常、操作の_後に_発生し、その結果の処理と関係があります。 操作が条件ステートメント内に組み込まれている場合、それが発生していることは単純にわかりにくくなります。 目が気が散る。 さらに、定義された変数の範囲は、それらが行の左端にある場合ほどすぐにはわかりません。
• エラーハンドラーは、意図的に関数として定義されていません（また、関数のようなセマンティクスに似たものもありません）。 これは私たちのためにいくつかのことをします：
  
  
  
  • コンパイラーは、参照先の名前付きハンドラーを単純にインライン化できます。 これは、関数呼び出しというよりも、単純なマクロ/コード生成テンプレートによく似ています。 ランタイムは、ハンドラーが存在することを知る必要さえありません。
  
  
  • ハンドラー内でできることは制限されていません。 check / handleの「このエラー処理フレームワークは、ベイルアウトにのみ適している」という批判を回避します。 また、「ハンドラーチェーン」の批判も回避します。 これらのハンドラーの1つに任意のコードを配置することができ、他の制御フローは暗示されません。
  
  
  • super returnを意味するために、ハンドラー内でreturnをハイジャックする必要はありません。 キーワードの乗っ取りは非常に混乱します。 return単にreturnを意味し、 super returnは実際には必要ありません。
  
  
  • deferは、エラー処理メカニズムとして月光を当てる必要はありません。 これは、主に資源などをクリーンアップする方法として考え続けることができます。
  
  
• エラーへのコンテキストの追加について：
  
  
  
  • ハンドラーを使用したコンテキストの追加は非常に簡単で、既存のif err != nilブロックと非常によく似ています。
  
  
  • 「ハンドラーなしで試す」構造はコンテキストの追加を直接奨励しませんが、ハンドラーフォームにリファクタリングするのは非常に簡単です。 その使用目的は主に開発中であり、未処理のエラーを強調するためにgo vetチェックを作成するのは非常に簡単です。
  
  

これらのアイデアが他の提案と非常に類似している場合はお詫びします—私はそれらすべてに遅れずについていくように努めましたが、かなりのことを逃した可能性があります。

@brynbellomyキーワード分析をありがとう-それは非常に役立つ情報です。 キーワードとしてのtryは問題ないようです。 （APIは影響を受けないとおっしゃっていますが、それは事実ですが、 tryはパラメーター名などとして表示される可能性があるため、ドキュメントを変更する必要があるかもしれません。ただし、これらのパッケージのクライアントには影響しないことに同意します。）

あなたの提案について：名前付きハンドラーがなくても問題ありませんか？ （これにより、電力を失うことなく提案が簡素化されます。インラインハンドラーからローカル関数を呼び出すだけで済みます。）

あなたの提案について：名前付きハンドラーがなくても問題ありませんか？ （これにより、電力を失うことなく提案が簡素化されます。インラインハンドラーからローカル関数を呼び出すだけで済みます。）

@griesemer確かに—私はそれらを含めることについてかなり生ぬるい感じでした。 確かにもっとゴーイッシュなし。

一方、人々はreturnのワンライナーを含むワンライナーエラー処理を実行する機能を望んでいるようです。 典型的なケースはログで、次にreturnです。 else句でローカル関数にシェルアウトすると、おそらくそれが失われます。

a, b := try SomeFunc() else err {
    someLocalFunc(err)
    return 0, err
}

（ただし、ifを合成するよりもこれを好む）

ただし、スレッドで前述した単純なgofmtの調整を実装することで、エラーコンテキストを追加するワンライナーリターンを取得できます。

a, b := try SomeFunc() else err { return 0, errors.Wrap(err, "bad stuff!") }

上記の提案で新しいキーワードは必要ですか？ なぜだめですか：

SomeFunc() else return
a, b := SomeOtherFunc() else err { return 0, errors.Wrap(err, "bad stuff!") }

@griesemerハンドラーがテーブルに戻った場合は、try / handleまたはtry / _label_の議論のために新しい問題を作成することをお勧めします。 この提案では特にハンドラーが省略されており、ハンドラーを定義して呼び出す方法は無数にあります。

ハンドラーを提案する人は、最初にチェック/ハンドルフィードバックウィキを読む必要があります。 あなたが夢見ているものは何でもそこにすでに説明されている可能性が高いです:-)
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback

@smonkewitzいいえ、そのバージョンでは、割り当てステートメントにバインドされているため、新しいキーワードは必要ありません。これは、これまでさまざまな構文糖衣構文で何度も言及されてきました。

https://github.com/golang/go/issues/32437#issuecomment -499808741
https://github.com/golang/go/issues/32437#issuecomment -499852124
https://github.com/golang/go/issues/32437#issuecomment -500095505

@ianlancetaylorは、この特定のエラー処理のフレーバーをgoチームによってまだ検討されていますか？ 提案された組み込みの試行ほど実装は簡単ではありませんが、より慣用的な感じがします。 〜不必要な声明、ごめんなさい。〜

@deanveloperと他の数人が言ったことを繰り返したいと思いますが、私自身の強調があります。 https://github.com/golang/go/issues/32437#issuecomment -498939499 @ deanveloperで次のように述べています。

tryは条件付きの戻り値です。 制御フローとリターンはどちらもGoのペデスタルで保持されます。 関数内のすべての制御フローはインデントされ、すべての戻り値はreturnで始まります。 これらの概念の両方を混ぜ合わせて、見逃しやすい関数呼び出しにすると、少し気分が悪くなります。

さらに、この提案では、 tryは値を返す関数であるため、より大きな式の一部として使用できます。

panicは、制御フローを変更する組み込み関数の先例をすでに設定していると主張する人もいますが、 panicは、次の2つの理由で根本的に異なると思います。

1. パニックは条件付きではありません。 常に呼び出し元の関数を中止します。
2. パニックは値を返さないため、スタンドアロンステートメントとしてのみ表示でき、可視性が向上します。

一方、試してみてください：

1. 条件付きです。 呼び出し元の関数から戻る場合と戻らない場合があります。
2. 値を返し、複合式に、場合によっては複数回、1行に表示され、エディターウィンドウの右マージンを超える可能性があります。

これらの理由から、 tryは「少し離れた」感じではなく、コードの可読性を根本的に損なうと思います。

今日、初めてGoコードに遭遇したとき、それをすばやくスキミングして、可能な出口点と制御フロー点を見つけることができます。 これはGoコードの非常に価値のあるプロパティだと思います。 tryを使用すると、そのプロパティがないコードを書くのが簡単になりすぎます。

コードの可読性を重視するGo開発者は、これらの可読性の落とし穴を回避するtryの使用法のイディオムに収束する可能性が高いことを認めます。 コードの可読性は多くのGo開発者にとってコアバリューであるように思われるので、そうなることを願っています。 しかし、 tryが既存のコードイディオムに十分な価値を追加して、誰もが学習できるように言語に新しい概念を追加するという重みを持ち、それが読みやすさを損なう可能性があることは私には明らかではありません。

`` ``
if it！= "broke" {
dontFix（it）
}

@ChrisHines要点（このスレッドの他の場所にエコーされます）に、別の制限を追加しましょう：

• tryステートメント（ハンドラーがない場合でも）は、独自の行で発生する必要があります。

それでも、視覚的なノイズを大幅に減らすことでメリットが得られます。 次に、 returnでアノテーションが付けられたリターンと、 tryでアノテーションが付けられた条件付きリターンが保証され、これらのキーワードは常に行の先頭（または最悪の場合、変数の割り当ての直後）になります。

したがって、このタイプのナンセンスはありません。

try EmitEvent(try (try DecodeMsg(m)).SaveToDB())

むしろこれ：

dm := try DecodeMsg(m)
um := try dm.SaveToDB()
try EmitEvent(um)

これはまだこれよりも明確に感じます：

dm, err := DecodeMsg(m)
if err != nil {
    return nil, err
}

um, err := dm.SaveToDB()
if err != nil {
    return nil, err
}

err = EmitEvent(um)
if err != nil {
    return nil, err
}

この設計で私が気に入っていることの1つは、エラーが発生する可能性があることを通知せずに、エラーを黙って無視することは不可能であるということです。 現在、 x, _ := SomeFunc() （無視された戻り値とは何ですか？エラー？何か他のものですか？）が表示されることがありますが、明確に注釈を付ける必要があります。

x := try SomeFunc() else err {}

提案を支持する前回の投稿以来、 @ jagv （パラメーターなしのtryは*error $を返す）と@josharian （ラベル付きエラーハンドラー）によって投稿された2つのアイデアを見てきました。わずかに変更されたフォームは、提案を大幅に強化します。

これらのアイデアを私が持っていた別のアイデアと組み合わせると、 tryの4つのバージョンがあります：

1. 試す（）
2. try（params）
3. try（params、label）
4. try（params、panic）

1は、エラー戻りパラメーター（ERP）へのポインターを返すか、パラメーターがない場合はnilを返します（＃4のみ）。 これにより、さらにブルトインを追加することなく、名前付きERPの代替手段が提供されます。

2は、現在想定されているとおりに機能します。 nil以外のエラーはすぐに返されますが、 deferステートメントで修飾できます。

3は、 @ josharianによって提案されたように機能します。つまり、nil以外のエラーでは、コードはラベルに分岐します。 ただし、デフォルトのエラーハンドララベルはありません。その場合は＃2に縮退するためです。

これは通常、 deferよりも簡単で高速なので、エラーを装飾する（またはローカルで処理してからnilを返す）ためのより良い方法であるように思われます。 それが気に入らなかった人は誰でも＃2を使うことができます。

エラー処理ラベル/コードを関数の終わり近くに配置し、関数本体の残りの部分に戻らないようにすることをお勧めします。 ただし、コンパイラが強制する必要はないと思います。これは、コンパイラが有用である場合があり、いずれの場合も強制が難しい場合があるためです。

したがって、通常のラベルとgotoの動作は、（ @ josharianが言ったように）サブジェクトを最初に修正される＃26058に適用しますが、とにかく修正する必要があると思います。

ラベルの名前をpanicにすることはできません。これは、＃4と競合するためです。

4は、戻ったり分岐したりするのではなく、すぐにpanicになります。 したがって、これが特定の関数で使用されるtryの唯一のバージョンである場合、ERPは必要ありません。

これを追加したので、テストパッケージは、組み込みの変更やその他の変更を必要とせずに、現在と同じように機能します。 ただし、他の_致命的な_シナリオでも役立つ場合があります。

これは、エラーハンドラーに分岐してパニックに陥る代わりに、ERPが必要になるため、 tryの別のバージョンである必要があります。

最初の提案に対する最も強力なタイプの反応の1つは、関数が戻る場所の通常のフローの容易な可視性を失うことに関する懸念でした。

たとえば、 @ deanveloperは、 https： //github.com/golang/go/issues/32437#issuecomment -498932961でその懸念を非常によく表現しました。これは、ここで最も賛成されたコメントだと思います。

@dominikhはhttps://github.com/golang/go/issues/32437#issuecomment-499067357に書き込みました：

gofmtされたコードでは、returnは常に/ ^ \ t * return /と一致します。これは、支援なしで目で確認するのは非常に簡単なパターンです。 一方、tryはコード内のどこでも発生する可能性があり、関数呼び出しの奥深くに任意にネストされます。 どんなに多くのトレーニングを行っても、ツールの支援なしに、関数内のすべての制御フローをすぐに見つけることができます。

それを助けるために、 @ brynbellomyは昨日提案しました：

すべてのtryステートメント（ハンドラーがない場合でも）は、独自の行で発生する必要があります。

さらに言えば、割り当ての場合でも、 tryが行の先頭である必要があります。

したがって、次のようになります。

try dm := DecodeMsg(m)
try um := dm.SaveToDB()
try EmitEvent(um)

以下ではなく（ @brynbellomyの例から）：

dm, err := DecodeMsg(m)
if err != nil {
    return nil, err
}

um, err := dm.SaveToDB()
if err != nil {
    return nil, err
}

err = EmitEvent(um)
if err != nil {
    return nil, err
}

それは、編集者やIDEの支援がなくても、ボイラープレートを減らしながら、かなりの量の可視性を維持するようです。

これは、名前付き結果パラメーターに依存する現在提案されている延期ベースのアプローチで機能するか、通常のハンドラー関数を指定して機能する可能性があります。 （名前付きの戻り値を必要とせずにハンドラー関数を指定することは、名前付きの戻り値を必要とするよりも私には良いように思えますが、それは別のポイントです）。

提案には次の例が含まれています。

info := try(try(os.Open(file)).Stat())    // proposed try built-in

代わりに次のようになります。

try f := os.Open(file)
try info := f.Stat()

それは、提案された構文ほど短くはないにしても、今日誰かが書くかもしれないものと比較して、ボイラープレートの削減です。 おそらくそれは十分に短いでしょう？

@ elagergren-spideroakはこの例を提供しました：

try(try(try(to()).parse().this)).easily())

私はそれがミスマッチなparensを持っていると思います、それはおそらく意図的なポイントまたは微妙なユーモアのビットです、それでその例が2 tryまたは3 tryを持つことを意図しているかどうかはわかりません。 いずれにせよ、おそらくtryで始まる2〜3行に分散する必要があるでしょう。

@thepudds 、これは私が以前のコメントで得ていたものです。 与えられたものを除いて

try f := os.Open(file)
try info := f.Stat()

明らかなことは、 tryを、複数の文を括弧で囲むことができるtryブロックと考えることです。 したがって、上記は

try (
    f := os.Open(file)
    into := f.Stat()
)

コンパイラがこれに対処する方法を知っている場合、同じことがネストにも機能します。 だから今、上記は

try info := os.Open(file).Stat()

関数のシグネチャから、コンパイラはOpenがエラー値を返す可能性があることを認識しており、tryブロックにあるため、エラー処理を生成してから、プライマリ戻り値に対してStat（）を呼び出す必要があります。

次に、エラー値が生成されていないか、ローカルで処理されるステートメントを許可します。 だからあなたは今言うことができます

try (
    f := os.Open(file)
    debug("f: %v\n", f) // debug returns nothing
    into := f.Stat()
)

これにより、tryブロックを再配置せずにコードを進化させることができます。 しかし、いくつかの奇妙な理由で、エラー処理は明示的に説明する必要があると人々は考えているようです。 彼らは欲しい

try(try(try(to()).parse()).this)).easily())

私は完全に元気ですが

try to().parse().this().easily()

どちらの場合でも、まったく同じエラーチェックコードを生成できます。 私の見解では、必要に応じていつでもエラー処理用の特別なコードを書くことができます。 try （または任意の呼び出し方）は、デフォルトのエラー処理（呼び出し元にパントすること）を単純に整理します。

もう1つの利点は、コンパイラーがデフォルトのエラー処理を生成する場合、上記の4つの機能のどれが失敗したかを知ることができるように、さらに識別情報を追加できることです。

tryが他の式の中に現れるプログラムの読みやすさについて少し心配しました。 そこで、標準ライブラリでgrep "return .*err$"を実行し、ブロックをランダムに読み始めました。 7214件の結果がありますが、私は数百件しか読んでいません。

最初に注意すべきことは、 tryが適用される場合、これらのブロックのほとんどすべてがもう少し読みやすくなることです。

2つ目は、これらのうち10分の1未満のごく少数が、別の式の中にtryを入れることです。 典型的なケースは、 x := try(...)または^try(...)$の形式のステートメントです。

tryが別の式の中に表示されるいくつかの例を次に示します。

テキスト/テン​​プレート

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        lessOrEqual, err := le(arg1, arg2)
        if err != nil {
                return false, err
        }
        return !lessOrEqual, nil
}

になります：

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        return !try(le(arg1, arg2)), nil
}

テキスト/テン​​プレート

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
...
        switch v.Kind() {
        case reflect.Map:
                index, err := prepareArg(index, v.Type().Key())
                if err != nil {
                        return reflect.Value{}, err
                }
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

になります

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                if x := v.MapIndex(try(prepareArg(index, v.Type().Key()))); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

（これは私が見た中で最も疑わしい例です）

正規表現/構文：

regexp/syntax/parse.go

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        if c, t, err = nextRune(t); err != nil {
                return nil, err
        }
        p.literal(c)
        ...
}

になります

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        c, t = try(nextRune(t))
        p.literal(c)
        ...
}

これは別の式の中で試してみる例ではありませんが、読みやすさを向上させるために呼び出したいと思います。 ここで、 cとtの値がifステートメントの範囲を超えて存在していることを確認するのははるかに簡単です。

ネット/ http

net / http / request.go：readRequest

        mimeHeader, err := tp.ReadMIMEHeader()
        if err != nil {
                return nil, err
        }
        req.Header = Header(mimeHeader)

になります：

        req.Header = Header(try(tp.ReadMIMEHeader())

データベース/ SQL

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                connector, err := driverCtx.OpenConnector(dataSourceName)
                if err != nil {
                        return nil, err
                }
                return OpenDB(connector), nil
        }

になります

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                return OpenDB(try(driverCtx.OpenConnector(dataSourceName))), nil
        }

データベース/ SQL

        si, err := ctxDriverPrepare(ctx, dc.ci, query)
        if err != nil {
                return nil, err
        }
        ds := &driverStmt{Locker: dc, si: si}

になります

        ds := &driverStmt{
                Locker: dc,
                si: try(ctxDriverPrepare(ctx, dc.ci, query)),
        }

ネット/ http

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                cc, err := p.t.dialclientconn(addr, singleuse)
                if err != nil {
                        return nil, err
                }
                return cc, nil
        }

になります

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                return try(p.t.dialclientconn(addr, singleuse))
        }

ネット/ http

func (f *http2Framer) endWrite() error {
        ...
        n, err := f.w.Write(f.wbuf)
        if err == nil && n != len(f.wbuf) {
                err = io.ErrShortWrite
        }
        return err
}

になります

func (f *http2Framer) endWrite() error {
        ...
        if try(f.w.Write(f.wbuf) != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

（これは私が本当に好きです。）

ネット/ http

        if f, err := fr.ReadFrame(); err != nil {
                return nil, err
        } else {
                hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
        }

になります

        hc = try(fr.ReadFrame()).(*http2ContinuationFrame)// guaranteed by checkFrameOrder

}

（またいいです。）

ネット：

        if ctrlFn != nil {
                c, err := newRawConn(fd)
                if err != nil {
                        return err
                }
                if err := ctrlFn(fd.ctrlNetwork(), laddr.String(), c); err != nil {
                        return err
                }
        }

になります

        if ctrlFn != nil {
                try(ctrlFn(fd.ctrlNetwork(), laddr.String(), try(newRawConn(fd))))
        }

多分これは多すぎます、そして代わりにそれはそうあるべきです：

        if ctrlFn != nil {
                c := try(newRawConn(fd))
                try(ctrlFn(fd.ctrlNetwork(), laddr.String(), c))
        }

全体として、私が読んだ標準ライブラリコードに対するtryの効果を非常に楽しんでいます。

最後のポイント：提案のいくつかの例を超えてコードを読むためにtryが適用されるのを見るのは、啓発的でした。 tryを使用するようにコードを自動的に変換するツールを作成することを検討する価値があると思います（プログラムのセマンティクスは変更されません）。 githubで人気のあるパッケージに対して生成されたdiffのサンプルを読んで、標準ライブラリで見つけたものが維持されるかどうかを確認するのは興味深いことです。 このようなプログラムの出力は、提案の効果についての追加の洞察を提供する可能性があります。

@crawshawこれをしてくれてありがとう、それが実際に動いているのを見るのは素晴らしかった。 しかし、それが実際に動作しているのを見ると、これまで却下していたインラインエラー処理に対する議論をより真剣に受け止めることができました。

これは、 tryをステートメントにするという@thepuddsの興味深い提案に非常に近いため、その構文を使用してすべての例を書き直し、式tryまたは現状維持、余分な行をあまり必要としない：

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                try index := prepareArg(index, v.Type().Key())
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        try c, t = nextRune(t)
        p.literal(c)
        ...
}

        try mimeHeader := tp.ReadMIMEHeader()
        req.Header = Header(mimeHeader)

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                try connector := driverCtx.OpenConnector(dataSourceName)
                return OpenDB(connector), nil
        }

これは、式を使用した方が間違いなく優れていますtry編集する必要のあるフィールドが複数ある場合は、 tryですが、それでもこのトレードオフのバランスを優先します

        try si := ctxDriverPrepare(ctx, dc.ci, query)
        ds := &driverStmt{Locker: dc, si: si}

これは基本的にこれの最悪のケースであり、問​​題ないように見えます。

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                try cc := p.t.dialclientconn(addr, singleuse)
                return cc, nil
        }

私はif tryが合法であるか合法であるかについて自分自身で議論しましたが、なぜ合法である必要がないのかについて合理的な説明を思い付くことができず、ここで非常にうまく機能します。

func (f *http2Framer) endWrite() error {
        ...
        if try n := f.w.Write(f.wbuf); n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

        try f := fr.ReadFrame()
        hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder

        if ctrlFn != nil {
                try c := newRawConn(fd)
                try ctrlFn(fd.ctrlNetwork(), laddr.String(), c)
        }

@crawshawの例をスキャンすると、制御フローが設計にさらに注意を払うのに十分なほど暗号化されていないことがよくあると確信できます。 少しでも複雑さを関連付けると、読みにくくなり、失敗しやすくなります。 オプションが検討されているのを見てうれしいですが、そのような保護された言語での制御フローを複雑にすることは、非常に性格が悪いようです。

func (f *http2Framer) endWrite() error {
        ...
        if try(f.w.Write(f.wbuf) != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

また、 tryは何も「試行」していません。 それは「保護リレー」です。 提案の基本セマンティクスがオフの場合、結果のコードにも問題があるのは驚きではありません。

func (f *http2Framer) endWrite() error {
        ...
        relay n := f.w.Write(f.wbuf)
        return checkShortWrite(n, len(f.wbuf))
}

ステートメントを試してみる場合は、フラグを使用して、どの戻り値とどのアクションを示すことができます。

try c, @      := newRawConn(fd) // return
try c, <strong i="6">@panic</strong> := newRawConn(fd) // panic
try c, <strong i="7">@hname</strong> := newRawConn(fd) // invoke named handler
try c, <strong i="8">@_</strong>     := newRawConn(fd) // ignore, or invoke "ignored" handler if defined

少なくともパニックと無視アクションには、サブ式構文が必要です（Russはそれが要件であると述べています）。

まず、 @ crawshawが、約200の実際の例を見て、上記の彼の思慮深い記事に時間を割いてくれたことに拍手を送ります。

次に、 @ jimmyfrasche 、 http2Framerの例に関するここでの回答について：

私はif tryが合法であるか合法であるかについて自分自身で議論しましたが、なぜ合法である必要がないのかについて合理的な説明を思い付くことができず、ここで非常にうまく機能します。

`` `
func（f * http2Framer）endWrite（）エラー{
..。
nを試してみる場合：= fwWrite（f.wbuf）; n！= len（f.wbuf）{
io.ErrShortWriteを返します
}
nilを返す
}

At least under what I was suggesting above in https://github.com/golang/go/issues/32437#issuecomment-500213884, under that proposal variation I would suggest `if try` is not allowed.

That `http2Framer` example could instead be:

func（f * http2Framer）endWrite（）エラー{
..。
nを試してください：= fwWrite（f.wbuf）
n！= len（f.wbuf）{の場合
io.ErrShortWriteを返します
}
nilを返す
}
`` That is one line longer, but hopefully still "light on the page". Personally, I think that (arguably) reads more cleanly, but more importantly it is easier to see the try`。

@deanveloperは上記のhttps://github.com/golang/go/issues/32437#issuecomment-49892961に書き込みました。

関数から戻ることは「神聖な」ことだったようです

その特定のhttp2Framerの例は、最終的には可能な限り短くはなりません。 ただし、 tryが行の最初のものでなければならない場合は、関数からの復帰をより「神聖な」ものにします。

@crawshawは言及しました：

2つ目は、これらのうち10分の1未満のごく少数が、別の式の中に試してみるということです。 典型的なケースは、x：= try（...）または^ try（...）$の形式のステートメントです。

特に、$＃ try tryが行の最初のものである必要がありますか？

@jimmyfrasche

@crawshawこれをしてくれてありがとう、それが実際に動いているのを見るのは素晴らしかった。 しかし、それが実際に動作しているのを見ると、これまで却下していたインラインエラー処理に対する議論をより真剣に受け止めることができました。

これは、 tryをステートメントにするという@thepuddsの興味深い提案に非常に近いため、その構文を使用してすべての例を書き直し、式tryまたは現状維持、余分な行をあまり必要としない：

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

最初の例は、私が式tryを強く好む理由をよく示しています。 あなたのバージョンでは、 leの呼び出しの結果を変数に入れる必要がありますが、その変数には、 leという用語がまだ意味していないという意味はありません。 したがって、意味がない（ xのように）または冗長な（ lessOrEqualのように）名前を付けることはできません。 式tryを使用すると、中間変数は必要ないため、この問題は発生しません。

匿名のままにしておくほうがよい名前を発明するために、精神的な努力を費やす必要はありません。

try （キーワード）が行の先頭に移動された最後のいくつかの投稿の背後でサポートを提供できることをうれしく思います。 returnと同じ視覚空間を共有する必要があります。

Re： @jimmyfrascheが複合ifステートメント内でtryを許可するという提案は、いくつかの理由から、ここで多くの人が避けようとしていることとまったく同じです。

• 2つの非常に異なる制御フローメカニズムを1つのラインに統合します
• try式が実際に最初に評価され、関数が返される可能性がありますが、 ifの後に表示されます。
• それらはまったく異なるエラーで返されます。そのうちの1つは実際にはコードに表示されませんが、もう1つはコードに表示されます。
• ブロックはハンドラーブロックによく似ているため、 tryが実際に処理されていないことがわかりにくくなります（まったく異なる問題を処理している場合でも）

tryを処理するように人々を促すことを好む、わずかに異なる角度からこの状況にアプローチすることができます。 try / else構文に後続の条件を含めることを許可するのはどうですか（これは、 errとnの両方を返す多くのI / O関数で一般的なパターンです。

func (f *http2Framer) endWrite() error {
        // ...
        try n := f.w.Write(f.wbuf) else err {
                return errors.Wrap(err, "error writing:")
        } else if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

.Writeによって返されたエラーを処理しない場合でも、 .Writeがエラーになる可能性があるという明確な注釈があります（@thepuddsが指摘しているように）。

func (f *http2Framer) endWrite() error {
        // ...
        try n := f.w.Write(f.wbuf)
        if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

2番目の@davedの応答。 私の意見では、 @ crawshawが強調表示した各例は、 tryの結果として、明確でなくなり、エラーが発生しやすくなりました。

try （キーワード）が行の先頭に移動された最後のいくつかの投稿の背後でサポートを提供できることをうれしく思います。 returnと同じ視覚空間を共有する必要があります。

この点で2つのオプションがあり、1つが選択され、将来の潜在的な機能の前例となると仮定すると、次のようになります。

A.）

try f := os.Open(filepath) else err {
    return errors.Wrap(err, "can't open")
}

B.）

f := try os.Open(filepath) else err {
    return errors.Wrap(err, "can't open")
}

2つのうちどちらが、将来の新しいキーワードの使用に対してより柔軟性を提供しますか？ _（私はコンパイラーを書くというダークアートをマスターしていないので、これに対する答えはわかりません。）_あるアプローチは別のアプローチよりも制限がありますか？

@davecheney @daved @crawshaw
私はこれについてDavesに同意する傾向があります。 @ crawshawの例では、他の多くのことが行われている行の奥深くに埋め込まれたtryステートメントがたくさんあります。 出口点を見つけるのは本当に難しい。 さらに、いくつかの例では、 tryのパレンがかなりひどく乱雑になっているようです。

このように変換された一連のstdlibコードを見ると非常に便利なので、同じ例を取り上げましたが、より制限の厳しい代替案に従って書き直しました。

• キーワードとしてtry
• 1行に1つだけtry
• tryは行の先頭にある必要があります

うまくいけば、これは私たちが比較するのに役立つでしょう。 個人的には、これらの例は元の例よりもはるかに簡潔に見えますが、制御フローを曖昧にすることはありません。 tryは、使用されている場所ならどこでも非常に目立ちます。

テキスト/テン​​プレート

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        lessOrEqual, err := le(arg1, arg2)
        if err != nil {
                return false, err
        }
        return !lessOrEqual, nil
}

になります：

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

テキスト/テン​​プレート

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
...
        switch v.Kind() {
        case reflect.Map:
                index, err := prepareArg(index, v.Type().Key())
                if err != nil {
                        return reflect.Value{}, err
                }
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

になります

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                try index := prepareArg(index, v.Type().Key())
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

正規表現/構文：

regexp/syntax/parse.go

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        if c, t, err = nextRune(t); err != nil {
                return nil, err
        }
        p.literal(c)
        ...
}

になります

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        try c, t = nextRune(t)
        p.literal(c)
        ...
}

ネット/ http

net / http / request.go：readRequest

        mimeHeader, err := tp.ReadMIMEHeader()
        if err != nil {
                return nil, err
        }
        req.Header = Header(mimeHeader)

になります：

        try mimeHeader := tp.ReadMIMEHeader()
        req.Header = Header(mimeHeader)

データベース/ SQL

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                connector, err := driverCtx.OpenConnector(dataSourceName)
                if err != nil {
                        return nil, err
                }
                return OpenDB(connector), nil
        }

になります

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                try connector := driverCtx.OpenConnector(dataSourceName)
                return OpenDB(connector), nil
        }

データベース/ SQL

        si, err := ctxDriverPrepare(ctx, dc.ci, query)
        if err != nil {
                return nil, err
        }
        ds := &driverStmt{Locker: dc, si: si}

になります

        try si := ctxDriverPrepare(ctx, dc.ci, query)
        ds := &driverStmt{Locker: dc, si: si}

ネット/ http

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                cc, err := p.t.dialclientconn(addr, singleuse)
                if err != nil {
                        return nil, err
                }
                return cc, nil
        }

になります

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                try cc := p.t.dialclientconn(addr, singleuse)
                return cc, nil
        }

ネット/ http
これは実際には行を節約しませんが、 if err == nilは比較的珍しい構造であるため、はるかに明確です。

func (f *http2Framer) endWrite() error {
        ...
        n, err := f.w.Write(f.wbuf)
        if err == nil && n != len(f.wbuf) {
                err = io.ErrShortWrite
        }
        return err
}

になります

func (f *http2Framer) endWrite() error {
        ...
        try n := f.w.Write(f.wbuf)
        if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

ネット/ http

        if f, err := fr.ReadFrame(); err != nil {
                return nil, err
        } else {
                hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
        }

になります

        try f := fr.ReadFrame()
        hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
}

ネット：

        if ctrlFn != nil {
                c, err := newRawConn(fd)
                if err != nil {
                        return err
                }
                if err := ctrlFn(fd.ctrlNetwork(), laddr.String(), c); err != nil {
                        return err
                }
        }

になります

        if ctrlFn != nil {
                try c := newRawConn(fd)
                try ctrlFn(fd.ctrlNetwork(), laddr.String(), c)
        }

@ james-lawrence https://github.com/golang/go/issues/32437#issuecomment -500116099への返信：オプションの, errが真剣に検討されているようなアイデアは思い出せません。 個人的には悪い考えだと思います。関数が変更されて末尾のerrorパラメーターが追加された場合、既存のコードはコンパイルを続行しますが、動作が大きく異なるためです。

エラーの処理にdeferを使用することは非常に理にかなっていますが、エラーに名前を付ける必要があり、新しい種類のif err != nilボイラープレートが必要になります。

外部ハンドラーはこれを行う必要があります：

func handler(err *error) {
  if *err != nil {
    *err = handle(*err)
  }
} 

のように使用されます

defer handler(&err)

外部ハンドラーを作成する必要があるのは1回だけですが、多くのエラー処理関数には2つのバージョンが必要です。1つは延期するためのもので、もう1つは通常の方法で使用するためのものです。

内部ハンドラーはこれを行う必要があります：

defer func() {
  if err != nil {
    err = handle(err)
  }
}()

どちらの場合も、アクセスするには、外部関数のエラーに名前を付ける必要があります。

スレッドで前述したように、これは単一の関数に抽象化できます。

func catch(err *error, handle func(error) error) {
  if *err != nil && handle != nil {
    *err = handle(*err)
  }
}

これは、 nilハンドラー関数のあいまいさに対する@griesemerの懸念に反するものであり、 errに名前を付ける必要があることに加えて、独自のdeferとfunc(err error) errorの定型文があります。外側の関数のerr 。

tryがキーワードとして使用される場合は、以下で説明するように、 catchキーワードを使用することも意味があります。

構文的には、 handleのようになります。

catch err {
  return handleThe(err)
}

意味的には、上記の内部ハンドラーコードの砂糖になります。

defer func() {
  if err != nil {
    err = handleThe(err)
  }
}()

やや不思議なため、名前が付けられていなくても、外部関数のエラーを取得する可能性があります。 （ catch $の後の$ err $は、 catchブロックのパラメーター名に似ています）。

catchには、 tryと同じ制限があり、どちらもそれに依存する砂糖であるため、最終的なエラーが返される関数内にある必要があります。

これは、元のhandleの提案ほど強力ではありませんが、エラーを処理するためにエラーに名前を付ける必要がなくなり、内部ハンドラーについて上記で説明した新しいボイラープレートが削除されます。外部ハンドラー用に個別のバージョンの関数が必要です。

複雑なエラー処理では、 tryを使用しない場合と同じように、 catchを使用しない必要がある場合があります。

これらは両方とも砂糖なので、 catchをtry $と一緒に使用する必要はありません。 catchハンドラーは、関数がnil以外のエラーを返すたびに実行されます。これにより、たとえば、いくつかのクイックログを保持できます。

catch err {
  log.Print(err)
  return err
}

または、返されたすべてのエラーをラップするだけです。

catch err {
  return fmt.Errorf("foo: %w", err)
}

@ianlancetaylor

_ "関数が変更されて末尾のerrorパラメータが追加された場合、既存のコードはコンパイルを続行しますが、動作が大きく異なるため、これは悪い考えだと思います。" _

これはおそらく正しい見方です。アップストリームコードとダウンストリームコードの両方を制御できる場合は、エラーを返すために関数シグネチャを変更する必要がある場合は、そうすることができます。

しかし、誰かが自分のパッケージのアップストリームまたはダウンストリームを制御しない場合はどうなるかを検討してください。 また、エラーが追加される可能性のあるユースケースを検討し、エラーを追加する必要があるが、ダウンストリームコードを強制的に変更できない場合はどうなりますか？

誰かが署名を変更して戻り値を追加する例を考えてみてください。 私にとって、彼らは通常、_「エラーが発生することに気づかなかった」_または_「エラーが発生しない可能性があるため、怠惰に感じて努力したくない」というカテゴリに分類されます。 _

どちらの場合も、エラーを処理する必要があることが明らかになるため、エラーリターンを追加する場合があります。 その場合、自分のパッケージを使用している他の開発者との互換性を壊したくないために署名を変更できない場合はどうすればよいですか？ 私の推測では、エラーが発生する時間の大部分と、エラーを返さないfuncを呼び出したコードは、非常に異なる動作をします。

実際、私は後者をめったに行いませんが、前者を頻繁に行います。 しかし、サードパーティのパッケージは、あるべき場所でのエラーのキャプチャを無視することがよくあります。これは、GoLandフラグでコードを表示すると、すべてのインスタンスが明るいオレンジ色になるためです。 よく使用するパッケージにエラー処理を追加するためにプルリクエストを送信できるようにしたいと思いますが、コードの署名が壊れてしまうため、ほとんどの場合は受け入れません。

関数によって返されるエラーを追加する下位互換性のある方法を提供しないことにより、コードを配布し、ユーザーのために物事を壊さないように気を配る開発者は、必要に応じてエラー処理を含めるようにパッケージを進化させることができなくなります。

たぶん、コードが異なる動作をするという問題を考えるのではなく、エラーを積極的にキャプチャしていないメソッドの欠点を最小限に抑える方法に関するエンジニアリング上の課題として問題を見るのではないでしょうか。 それはより広く、より長期的な価値を持つでしょう。

たとえば、エラーを無視できるようになる前に設定する必要があるパッケージエラーハンドラーを追加することを検討してください。

率直に言って、通常の戻り値に加えてエラーを返すというGoのイディオムは、その優れた革新の1つでした。 しかし、物事を改善するときによくあることですが、他の弱点を明らかにすることがよくあります。Goのエラー処理は十分に革新していなかったと私は主張します。

私たちGophersは例外をスローするのではなくエラーを返すことに没頭しているので、私が持っている質問は_「なぜすべての関数からエラーを返すべきではないのですか？」それを使ってコーディングするよりも便利です。 したがって、エラー処理から逃れることができると考える場合は、エラー処理を省略します。 しかし、私たちはしばしば間違っていると思います。

したがって、実際には、コードをエレガントで読みやすくする方法を理解できれば、戻り値とエラーは実際には別々に処理する必要があり、 _every_関数には過去の関数シグネチャに関係なくエラーを返す機能が必要であると主張します。 また、既存のコードでエラーを生成するコードを適切に処理できるようにすることは、価値のある取り組みです。

実行可能な構文を想像できなかったため、何も提案していませんが、正直に言うと、このスレッドのすべてがGoのエラー処理に関連しているわけではなく、エラー処理とプログラムロジックは奇妙な仲間なので、理想的にはエラーは何らかの方法で帯域外で処理するのが最善でしょうか？

キーワードとしてのtryは、確かに読みやすさ（関数呼び出しと比較して）に役立ち、それほど複雑ではないようです。 @brynbellomy @crawshaw例を書くために時間を割いていただき、ありがとうございます。

私の一般的な考えは、 tryはやりすぎだと思います。 それは解決します：関数を呼び出し、変数を割り当て、エラーをチェックし、存在する場合はエラーを返します。 代わりにスコープを切り取り、条件付きの戻り値のみを解決することを提案します：「最後の引数がnilでない場合は戻り値」。

これはおそらく新しいアイデアではありません...しかし、エラーフィードバックウィキで提案をざっと読んだ後、私はそれを見つけられませんでした（それがそこにないという意味ではありません）

条件付きリターンに関するミニ提案

抜粋：

err, thing := newThing(name)
refuse nil, err

ウィキにも「代替案」の下に追加しました

何もしないことも非常に合理的な選択肢のようです。

@alexhornbakeは、少し違うアイデアを私に与えてくれます。

assert(nil, err)
assert(len(a), len(b))
assert(true, condition)
assert(expected, given)

このように、エラーチェックだけでなく、多くの種類の論理エラーにも適用されます。

指定されたものはエラーにラップされて返されます。

@alexhornbake

tryが実際に試行していないように、 refuseは実際には「拒否」していません。 ここでの一般的な目的は、有線の値の1つが条件を満たしたときに「トリップ」する「保護リレー」（ relayは短く、正確で、 returnに頭韻法）を設定することです。 （つまり、nil以外のエラーです）。 これは一種のサーキットブレーカーであり、設計が面白くないケースに限定されていて、最もぶら下がっているボイラープレートの一部を単純に減らすことができれば、付加価値が得られると思います。 リモートで複雑なものはすべて、プレーンなGoコードに依存する必要があります。

また、cranshawが標準ライブラリを調べて作業したことを称賛しますが、結論は大きく異なります...これらのコードスニペットのほとんどすべてが読みにくくなり、誤解されやすくなると思います。

        req.Header = Header(try(tp.ReadMIMEHeader())

これがエラーになる可能性があることを私はしばしば見逃します。 簡単に読むと、「わかりました。ヘッダーをReadMimeHeaderのヘッダーに設定してください」と表示されます。

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                return OpenDB(try(driverCtx.OpenConnector(dataSourceName))), nil
        }

これ、私の目はちょうどそのOpenDB行を解析しようとして交差します。 そこには非常に多くの密度があります...これは、ネストされたすべての関数呼び出しが抱える大きな問題を示しています。つまり、内側から読み取らなければならず、最も内側の部分がどこにあるかを把握するために頭の中で解析する必要があります。 。

また、これは同じ行の2つの異なる場所から戻る可能性があることに注意してください。デバッグします。この行からエラーが返されたと表示されます。誰もが最初に行うことは、実際にOpenConnectorが失敗しているのに（またはその逆の場合）、OpenDBがこの奇妙なエラーで失敗している理由を理解してください。

        ds := &driverStmt{
                Locker: dc,
                si: try(ctxDriverPrepare(ctx, dc.ci, query)),
        }   

これは、以前は不可能だったコードが失敗する可能性がある場所です。 tryがないと、構造体リテラルの構築は失敗しません。 私の目は「OK、driverStmtを構築しています...先に進みます..」のようにそれをざっと見ます。見逃しやすいので、実際には、関数がエラーになる可能性があります。 以前に可能だった唯一の方法は、ctxDriverPrepareがパニックになった場合です...そして、1。）基本的には発生しないはずであり、2。）発生した場合は、何かが大幅に間違っていることを意味します。

キーワードとステートメントを試してみると、それに関する私の問題の多くが修正されます。 私はそれが下位互換性がないことを知っていますが、それのより悪いバージョンを使用することが下位互換性の問題の解決策であるとは思いません。

@davedフォローするかどうかわかりません。 名前が嫌いですか、それともアイデアが嫌いですか？

とにかく、私は代わりにこれをここに投稿しました...正当な関心がある場合は、議論のために新しい問題を開くことができます、このスレッドを汚染したくない（多分遅すぎますか？）元のアイデアの親指を上/下にすると私たちの感覚...もちろん、別の名前を受け入れます。 重要なのは「割り当てを処理しようとしない条件付きリターン」です。

@jimmyfrascheによるキャッチの提案は好きですが、別の方法を提案したいと思います。
go handler fmt.HandleErrorf("copy %s %s", src, dst)
と同等になります：
go defer func(){ if(err != nil){ fmt.HandleErrorf(&err,"copy %s %s", src, dst) } }()
ここで、errは、タイプエラーのある最後の名前の戻り値です。 ただし、戻り値に名前が付けられていない場合は、ハンドラーを使用することもできます。 より一般的なケースも許可されます。
go handler func(err *error){ *err = fmt.Errorf("foo: %w", *err) }() `
名前付きの戻り値（catchは解決しません）を使用する際の主な問題は、errが不要であるということです。 fmt.HandleErrorfのようなハンドラーへの呼び出しを延期する場合、エラーの戻り値へのポインターを除いて、合理的な最初の引数はありません。なぜユーザーに間違いを犯すオプションを与えるのでしょうか。

catchと比較すると、主な違いは、ハンドラーを使用すると、事前定義されたハンドラーを呼び出すのが少し簡単になりますが、それらを適切に定義するための冗長性が増します。 これが理想的かどうかはわかりませんが、当初の提案に沿っていると思います。

@yiyus catch 、私が定義したように、 catchを含む関数でerrという名前を付ける必要はありません。

catch err {では、 errは、 catchブロック内のエラーの名前です。 これは、関数のパラメーター名のようなものです。

これで、通常のfmt.Errorfを使用できるため、 fmt.HandleErrorfのようなものは必要ありません。

func f() error {
  catch err {
    return fmt.Errorf("foo: %w", err)
  }
  return errors.New("bar")
}

これは、 foo: barとして出力されるエラーを返します。

私はこのアプローチが好きではありません。理由は次のとおりです。

• try()関数呼び出しは、親関数のコード実行を中断します。
• returnキーワードはありませんが、コードは実際に戻ります。

ハンドラーを実行する方法はたくさん提案されていますが、2つの重要な要件を見逃していることがよくあると思います。

1. 大幅に異なり、 if x, err := thingie(); err != nil { handle(err) }よりも優れている必要があります。 try x := thingie else err { handle(err) }に沿った提案は、その基準を満たしていないと思います。 ifとだけ言ってみませんか？

2. deferの既存の機能と直交している必要があります。 つまり、ハンドルと延期が相互作用するときに奇妙なコーナーケースを作成することなく、提案された処理メカニズムがそれ自体で必要であることは明らかであるほど、十分に異なっている必要があります。

try / handleの代替メカニズムについて説明するので、これらのdesiderataを覚えておいてください。

@carlmjohnson私はあなたのポイント2に関する@jimmyfrascheのcatchのアイデアが好きです-それは2行を節約し、エラーの戻り値に名前を付ける必要をなくすことができるdeferの単なる構文糖衣ですまた、まだ行っていない場合は、他のすべての名前を付ける必要があります）。 deferであるため、 deferとの直交性の問題は発生しません。

@ubombiが言ったことをエコーし​​ます：

try（）関数呼び出しは、親関数のコード実行を中断します。; returnキーワードはありませんが、コードは実際に戻ります。

Rubyでは、procsとlambdasはtryが行うことの例です... procは、returnステートメントがブロック自体からではなく呼び出し元から返すコードのブロックです。

これはまさにtryが行うことです...これは事前定義されたRubyプロシージャです。

そのルートに行く場合は、 proc functionsを導入することで、実際にユーザーに独自のtry関数を定義させることができると思います。

$＃$ 4 $＃$の方が読みやすいので、私はまだif err != nilを好みますが、ユーザーが独自のプロシージャを定義した場合、 tryの方が有益だと思います。

proc try(err *error, msg string) {
  if *err != nil {
    *err = fmt.Errorf("%v: %w", msg, *err)
    return
  }
}

そして、あなたはそれを呼ぶことができます：

func someFunc() (string, error) {
  err := doSomething()
  try(&err, "someFunc failed")
}

ここでの利点は、独自の用語でエラー処理を定義できることです。 また、 proc公開、非公開、または内部にすることもできます。

また、元のGo2プロポーザルのhandle {}句よりも優れています。これは、各関数ではなく、コードベース全体に対して1回だけ定義できるためです。

読みやすさに関する考慮事項の1つは、func（）とproc（）がfunc()やproc!()などの異なる方法で呼び出される可能性があるため、プログラマーはproc呼び出しが実際に関数を呼び出します。

@ marwan-at-work、あなたの例ではtry(err, "someFunc failed")をtry(&err, "someFunc failed")にすべきではありませんか？

@dpinela訂正していただきありがとうございます、コードを更新しました:)

ここでオーバーライドしようとしている一般的な方法は、例外として、多くの言語での標準スタックの巻き戻しが示唆していることです（したがって、「try」という単語が選択されました...）。
しかし、トレース内の2つのレベルにジャンプバックする関数（... try（）またはその他）のみを許可できる場合は、

try := handler(err error) {     //which corelates with - try := func(err error) 
   if err !=nil{
       //do what ever you want to do when there's an error... log/print etc
       return2   //2 levels
   }
} 

そして次のようなコード
f：= try（os.Open（filename））
提案がアドバイスするとおりに実行できますが、その関数（または実際には「ハンドラー関数」）として、開発者は関数の機能、さまざまな場合のエラーのフォーマット方法、あらゆる場所で同様のハンドラーを使用する方法をより詳細に制御できます。毎回fmt.Errorf（ "error open file％s ...."）を作成する代わりに、os.Openを処理するコード（たとえば）。
これにより、「try」が定義されていないかのようにエラー処理が強制されます。これはコンパイル時のエラーです。

@guybrandこのような2レベルのリターンreturn2 （または一般的な概念がSmalltalkで呼ばれる「非ローカルリターン」）を持つことは、優れた汎用メカニズムです（＃32473の@mikeschinkelによっても提案されています） 。 しかし、あなたの提案にはまだtryが必要なようですので、 return2の理由はわかりません- tryはreturnを実行できますtryをローカルに書き込むこともできればもっと興味深いでしょうが、それは任意の署名では不可能です。

@griesemer

_ "したがって、 return2の理由はわかりません- tryはreturnを実行できます。" _

理由の1つは、＃32473 _（参照に感謝）_で指摘したように、 returnに加えて、 breakとcontinueの複数のレベルを許可することです。

すべての新しいコメントをありがとうございました。 議論に遅れずについていき、広範なフィードバックを書くことは、かなりの時間の投資です。 そしてさらに良いことに、時には情熱的な議論にもかかわらず、これはこれまでのところかなり市民的なスレッドでした。 ありがとう！

ここにもう1つの簡単な要約がありますが、今回はもう少し凝縮されています。 私が言及しなかった、忘れた、または誤解した人々に謝罪します。 この時点で、いくつかのより大きなテーマが出現していると思います。

1）一般に、 try機能に組み込みを使用することは、悪い選択であると思われます。制御フローに影響を与えることを考えると、少なくとも_キーワードにする必要があります（ @carloslenz "は、括弧"）; tryは、式としては良い考えではないようです。読みやすさを損なう（ @ ChrisHines 、@ jimmyfrasche）、「 returnなしのリターン」です。 @brynbellomyは、識別子として使用されるtryの実際の分析を行いました。 パーセンテージ的には非常に少ないように見えるので、あまりにも多くのコードに影響を与えることなく、キーワードルートに進むことができるかもしれません。

2） @crawshawは、stdライブラリから数百のユースケースを分析するのに少し時間がかかり、提案されたtryはほとんど常に読みやすさを改善したという結論に達しました。 @jimmyfrascheは反対の結論に達しました。

3）もう1つのテーマは、エラー装飾にdeferを使用することは理想的ではないということです。 @josharianは、 defer常に関数の戻り時に実行されることを指摘していますが、エラー装飾のためにここにある場合は、エラーが発生した場合にのみボディを気にします。これは混乱の原因となる可能性があります。

4）多くの人が提案を改善するための提案を書きました。 @ zeebo 、@ patrick-nytは、1行に単純なifステートメントをフォーマットするgofmtを支持しています（そして現状に満足しています）。 @jargvは、 try() （引数なし）が現在「保留中」のエラーへのポインターを返す可能性があることを示唆しました。これにより、 deferでアクセスできるように、エラー結果に名前を付ける必要がなくなります。 @masteradaは、代わりにerrorfunc()を使用することを提案しました。 @velovixは、2番目の引数がエラーハンドラーになる2つの引数tryのアイデアを復活させました。

@ klaidliadon 、 @ networkimprovは、 try f, # := os.Open()のような特別な「代入演算子」を支持しています。 @networkimprovは、そのようなアプローチを調査するより包括的な代替案を提出しました（問題＃32500を参照）。 @mikeschinkelは、エラー固有のtryではなく、エラー処理にも使用できる2つの新しい汎用言語機能を導入することを提案する代替案も提出しました（問題＃32473を参照）。 @josharianは、昨年GopherConで話し合った可能性を復活させました。この場合、 tryはエラー時に返されませんが、代わりに（ gotoを使用して） errorという名前のラベルにジャンプします（または、 tryはターゲットラベルの名前をとる場合があります）。

5）キーワードとしてtryをテーマに、2つの考えが浮かび上がってきました。 @brynbellomyは、代わりにハンドラーを指定する可能性のあるバージョンを提案しました。

a, b := try f()
a, b := try f() else err { /* handle error */ }

@thepuddsはさらに一歩進んで、行の先頭にtryを提案し、 tryにreturnと同じ可視性を与えます。

try a, b := f()

これらは両方ともdeferで機能する可能性があります。

@griesemer

@ mikeschinkel ＃32473への参照をありがとう、それは多くの共通点を持っています。

それにかんする

しかし、あなたの提案にはまだ試してみる必要があるようです
私の提案は、予約された「ビルドイン/キーワード/式」ではなく「任意の」ハンドラーで実装できますが、「try（）」は悪い考えではないと思います（したがって、反対票を投じませんでした）。 「それを広げる」ために-それはより多くの利点を示すでしょう、多くの人は「一度行く2.0が導入される」と期待していました

これは、前回の要約で報告した「混合バイブ」の原因でもあると思います。「try（）はエラー処理を改善しません」ではありません。確かに、「Go3.0が他の主要なエラーを解決するのを待っています」苦痛を処理する」上記の人々は、長すぎるように見えます:)

私は「エラー処理の苦痛」について調査を行っています（そして、苦痛のいくつかは単に「私は良い習慣を使わない」であると思われますが、人々（主に他の言語から来ている）がやりたいとさえ想像していなかったものもあります-クールからWTFへ）。

すぐにいくつかの興味深い結果を共有できることを願っています。

最後に-素晴らしい仕事と忍耐に感謝します！

現在提案されている構文の長さと現在利用可能な構文の長さを単純に見ると、エラーを処理したり装飾したりせずにエラーを返す必要がある場合が、最も便利な場合です。 これまでの私のお気に入りの構文の例：

try a, b := f() else err { return fmt.Errorf("Decorated: %s", err); }
if a,b, err :=f;  err != nil { return fmt.Errorf("Decorated: %s", err); }
try a, b := f()
if a,b, err :=f;  err != nil { return err; }

ですから、私が以前考えていたものとは異なり、少なくとも装飾/処理されたエラーの場合は、gofmtを変更するだけで十分かもしれません。 エラーケースを渡すだけですが、この非常に一般的なユースケースの構文糖衣構文としては、tryのようなものが依然として望ましい場合があります。

try elseに関しては、最初のコメントのfmt.HandleErrorf （編集：入力がnilの場合はnilを返すと仮定しています）のような条件付きエラー関数は正常に機能すると思いますので、 elseを追加します不要です。

a, b, err := doSomething()
try fmt.HandleErrorf(&err, "Decorated "...)

ここにある他の多くの人と同様に、私はtryを式ではなくステートメントにすることを好みます。これは主に、制御フローを変更する式がGoにとって完全に異質であるためです。 また、これは式ではないため、行の先頭に配置する必要があります。

名前が適切でないことにも@davedに同意します。 結局のところ、ここで達成しようとしているのは保護された割り当てです。Swiftのようにguardを使用して、 else句をオプションにしてみませんか？ 何かのようなもの

GuardStmt = "guard" ( Assignment | ShortVarDecl | Expression ) [  "else" Identifier Block ] .

ここで、 Identifierは、次のBlockにバインドされているエラー変数名です。 else句がない場合は、現在の関数から戻るだけです（必要に応じて、deferハンドラーを使用してエラーを装飾します）。

else句は、通常の割り当ての後にif err != nilが続く構文糖衣構文であるため、最初は好きではありませんでしたが、いくつかの例を示した後は、 guardを使用するのが理にかなっています。

編集： catchのようなものを使用して、何らかの方法でさまざまなエラーハンドラーを指定することを提案する人もいます。 私はelseが意味論的に同じように実行可能であり、それはすでにその言語にあると思います。

私はtry-elseステートメントが好きですが、この構文はどうですか？

a, b, (err) := func() else { return err }

式try - elseは三項演算子です。

a, b := try f() else err { ... }
fmt.Println(try g() else err { ... })`

ステートメントtry - elseはifステートメントです。

try a, b := f() else err { ... }
// (modulo scope of err) same as
a, b, err := f()
if err != nil { ... }

オプションのハンドラーを備えた組み込みのtryは、ヘルパー関数（下記）を使用するか、 tryを使用しないで実現できます（図には示されていませんが、どのように見えるかは誰もが知っています）。

a, b := try(f(), decorate)
// same as
a, b := try(g())
// where g is
func g() (whatever, error) {
  x, err := f()
  if err != nil {
    try(decorate(err))
  }
  return x, nil
}

3つすべてが定型文を削減し、エラーの範囲を抑えるのに役立ちます。

組み込みのtryで最も節約できますが、設計ドキュメントに記載されている問題があります。

ステートメントtry - elseの場合、 try ifを使用するよりも利点があります。 しかし、その利点はごくわずかであるため、私はそれが好きですが、それが正当化されるのを見るのに苦労しています。

3つすべてが、個々のエラーに対して特別なエラー処理が必要になるのが一般的であることを前提としています。

すべてのエラーを平等に処理するには、 defer使用します。 同じエラー処理が各elseブロックで実行されている場合、少し繰り返します。

func printSum(a, b string) error {
  try x := strconv.Atoi(a) else err {
    return fmt.Errorf("printSum: %w", err)
  }
  try y := strconv.Atoi(b) else err {
    return fmt.Errorf("printSum: %w", err)
  }
  fmt.Println("result:", x + y)
  return nil
}

特定のエラーが特別な処理を必要とする場合があることを私は確かに知っています。 それらは私の記憶に突き出ているインスタンスです。 しかし、それが100回に1回しか発生しない場合は、 tryを単純に保ち、そのような状況ではtryを使用しない方がよいのではないでしょうか。 一方、10回に1回のようであれば、 else / handlerを追加する方が合理的と思われます。

else try $とelse / handlerありのtryの実際の分布を確認するのは興味深いことですが、収集するのは簡単なデータではありません。

@jimmyfrascheの最近のコメントを拡張したいと思います。

この提案の目的は、定型文を減らすことです

    a, b, err := f()
    if err != nil {
        return nil, err
    }

このコードは読みやすいです。 ボイラープレートを大幅に削減できる場合にのみ、言語を拡張する価値があります。 私が次のようなものを見たとき

    try a, b := f() else err { return nil, err }

あまり節約していないと感じずにはいられません。 3行節約できます。これは良いことですが、私の計算では56文字から46文字に削減しています。 それほど多くはありません。 と比較する

    a, b := try(f())

これは56文字から18文字に削減され、はるかに大幅に削減されます。 tryステートメントは制御フローの潜在的な変更をより明確にしますが、全体として、ステートメントがより読みやすくなるとは思いません。 プラス面としては、 tryステートメントを使用すると、エラーに注釈を付けるのが簡単になります。

とにかく、私のポイントは、何かを変更する場合は、ボイラープレートを大幅に削減するか、大幅に読みやすくする必要があるということです。 後者はかなり難しいので、変更は前者で実際に機能する必要があります。 ボイラープレートがわずかに減少しただけの場合、私の意見ではそれを行う価値はありません。

他の人と同じように、例を挙げてくれた@crawshawに感謝します。

これらの例を読むときは、 try関数による制御の流れを気にしないという考え方を採用することをお勧めします。 おそらく間違っていると思いますが、その制御の流れは、言語を知っている人々にとってすぐに第二の性質になると思います。 通常の場合、エラーの場合に何が起こるかについて心配するのをやめるだけだと思います。 すでにif err != nil { return err }をグレージングしているのと同じように、 tryをグレージングしながらこれらの例を読んでみてください。

ここですべてを読んだ後、さらに熟考すると、追加する価値のあるステートメントとしても試してみることができるかどうかはわかりません。

1. その理由は、ボイラープレートコードの処理エラーを減らすことのようです。 私見では、コードを「整理」しますが、実際には複雑さを取り除くことはできません。 それはただそれを覆い隠します。 これには十分な理由がないようです。 外出「コンカレントスレッドを開始することで構文が美しくキャプチャされました。ここではそのような「あはは！」という感覚は得られません。正しく感じられません。費用便益比が十分に大きくありません。

2. その名前はその機能を反映していません。 最も単純な形式では、「関数がエラーを返す場合は、呼び出し元からエラーを返す」ということですが、それは長すぎます:-)少なくとも別の名前が必要です。

3. tryの暗黙のエラー復帰により、Goはしぶしぶ例外処理に戻っているように感じます。 つまり、Aがトライガードにあり、BがトライガードでCを呼び出し、CがトライガードでDを呼び出した場合、Dが事実上エラーを返した場合、非ローカルgotoが発生します。 それはあまりにも「魔法」のように感じます。

4. それでも私はもっと良い方法が可能かもしれないと信じています。 今すぐ試すを選択すると、そのオプションが閉じられます。

@ianlancetaylor
「他の方法で試す」提案を正しく理解している場合、 elseブロックはオプションであり、ユーザー提供の処理用に予約されているようです。 あなたの例では、 try a, b := f() else err { return nil, err } else句は実際には冗長であり、式全体は単純にtry a, b := f()と書くことができます。

@ianlancetaylorに同意します、
読みやすさと定型文は2つの主要な懸念事項であり、おそらく
go 2.0エラー処理（他の重要な懸念事項を追加できますが）

また、その現在

a, b, err := f()
if err != nil {
    return nil, err
}

非常に読みやすいです。
そして私は信じているので

if a, b, err := f(); err != nil {
    return nil, err
}

ほぼ同じくらい読みやすいですが、その範囲は「問題」であり、おそらく

ifErr a, b, err := f() {
    return nil, err
}

それだけです; err！= nil部分であり、スコープを作成しない、または

同様に

a、b、errを試してください：= f（）{
nilを返し、エラー
}

余分な2行を保持しますが、それでも読み取り可能です。

2019年6月11日火曜日、20：19 Dmitriy Matrenichev、 notifications @ github.com
書きました：

@ianlancetaylor https://github.com/ianlancetaylor
「elseを試す」提案を正しく理解していれば、elseがブロックしているようです
オプションであり、ユーザー提供の処理用に予約されています。 あなたの例では
try a、b：= f（）else err {return nil、err} else句は実際には
冗長であり、式全体は単にtry a、b：=のように書くことができます。
f（）

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/32437?email_source=notifications&email_token=ABNEY4XPURMASWKZKOBPBVDPZ7NALA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOOR
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABNEY4SAFK4M5NLABF3NZO3PZ7NALANCNFSM4HTGCZ7Q
。

@ianlancetaylor

とにかく、私のポイントは、何かを変更する場合は、ボイラープレートを大幅に削減するか、大幅に読みやすくする必要があるということです。 後者はかなり難しいので、変更は前者で実際に機能する必要があります。 ボイラープレートがわずかに減少しただけの場合、私の意見ではそれを行う価値はありません。

同意し、 elseは構文糖衣構文（奇妙な構文で！）にすぎず、めったに使用されない可能性が高いことを考えると、私はそれについてあまり気にしません。 それでも、ステートメントとしてtryを使用したいと思います。

@ianlancetaylor @DmitriyMVをエコーすると、 elseブロックはオプションになります。 両方を説明する例を紹介します（実際のコードで処理されたブロックと処理されていないtryブロックの相対的な比率に関してはそれほど遠くないようです）。

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    headRef, err := r.Head()
    if err != nil {
        return err
    }

    parentObjOne, err := headRef.Peel(git.ObjectCommit)
    if err != nil {
        return err
    }

    parentObjTwo, err := remoteBranch.Reference.Peel(git.ObjectCommit)
    if err != nil {
        return err
    }

    parentCommitOne, err := parentObjOne.AsCommit()
    if err != nil {
        return err
    }

    parentCommitTwo, err := parentObjTwo.AsCommit()
    if err != nil {
        return err
    }

    treeOid, err := index.WriteTree()
    if err != nil {
        return err
    }

    tree, err := r.LookupTree(treeOid)
    if err != nil {
        return err
    }

    remoteBranchName, err := remoteBranch.Name()
    if err != nil {
        return err
    }

    userName, userEmail, err := r.UserIdentityFromConfig()
    if err != nil {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    _, err = r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    if err != nil {
        return err
    }
    return nil
}

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    try headRef := r.Head()
    try parentObjOne := headRef.Peel(git.ObjectCommit)
    try parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    try parentCommitOne := parentObjOne.AsCommit()
    try parentCommitTwo := parentObjTwo.AsCommit()
    try treeOid := index.WriteTree()
    try tree := r.LookupTree(treeOid)
    try remoteBranchName := remoteBranch.Name()
    try userName, userEmail := r.UserIdentityFromConfig() else err {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    try r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    return nil
}

try / elseパターンは、複合ifに比べて多くの文字を保存しませんが、次のようになります。

• エラー処理構文を未処理のtryと統合します
• 条件付きブロックがエラー状態を処理していることを一目で明確にします
• 複合ifが苦しんでいるスコープの奇妙さを減らす機会を与えてください

ただし、未処理のtryが最も一般的です。

@ianlancetaylor

err！= nil {return err}の場合、すでに釉薬をかけているのと同じように、釉薬をかけながらこれらの例を読んでみてください。

私はそれが可能/同等だとは思いません。 混雑した行に試行が存在するか、それが正確に何をラップするか、または1行に複数のインスタンスがあることを見逃しています...これらは、リターンポイントを簡単/迅速にマークし、その中の詳細を気にしないことと同じではありません。

@ianlancetaylor

一時停止の標識を見ると、そこに印刷されている単語を読んでその深い意味を熟考するよりも、形や色でそれを認識します。

私の目はif err != nil { return err }に釉薬をかけるかもしれませんが、それと同時に、はっきりと瞬時に登録されます。

tryステートメントのバリエーションについて私が気に入っているのは、ボイラープレートを減らすことですが、釉薬をかけやすく、見逃しにくい方法です。

あちこちに余分な行があることを意味するかもしれませんが、それでも現状よりも少ない行です。

@brynbellomy

1. 次のような複数の値を返す関数をどのように処理しますか。
   func createMergeCommit（r * repo.Repo、index * git.Index、remote * git.Remote、remoteBranch * git.Branch）（ハッシュ、エラー）{
2. エラーを返した正しい行をどのように追跡しますか
3. スコープの問題（他の方法で解決される可能性があります）を破棄するかどうかはわかりません

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {

    if headRef, err := r.Head(); err != nil {
        return err
    } else if parentObjOne, err := headRef.Peel(git.ObjectCommit); err != nil {
        return err
    } else parentObjTwo, err := remoteBranch.Reference.Peel(git.ObjectCommit); err != nil {
        return err
    } ...

読みやすさに関してはそれほど違いはありませんが（またはfmt.Errorf（ "error with get head：％s"、err.Error（））を使用すると、追加のデータを簡単に変更して指定できます。

まだナグなのは

1. 再確認する必要があります; エラー！= nil
2. 追加情報を提供したくない場合は、エラーをそのまま返します。これは、場合によっては適切な方法ではないため、呼び出した関数に依存して、「何がうまくいかなかったか」を示唆する「適切な」エラーを反映しているためです。 "、file.Open、close、Remove、Db関数などの場合、関数呼び出しの多くは同じエラーを返す可能性があります（それは、エラーを書いた開発者が良い仕事をしたかどうかを意味するかどうかを議論することができます...しかしそれは発生します）-そして-エラーが発生しました。おそらく、呼び出した関数からログに記録します。
   「createMergeCommit」ですが、発生した正確な行まで追跡できません。

誰かがすでにこのようなものを投稿している場合は申し訳ありません（良いアイデアがたくさんあります：P）この代替構文はどうですか？

fail := func(err error) error {
  log.Print("unexpected error", err)
  return err
}

a, b, err := f1()          // normal
c, d := f2() -> throw      // calls throw(err)
e, f := f3() -> panic      // calls panic(err)
g, h := f4() -> t.Error    // calls t.Error(err)
i, j := f5() -> fail       // calls fail(err)

つまり、返されたerr！= nilの場合に呼び出される関数呼び出しの右側に、 -> handlerがあります。 ハンドラーは、エラーを単一の引数として受け入れ、オプションでエラーを返す関数です（つまり、 func(error)またはfunc(error) error ）。 ハンドラーがnilエラーを返した場合、関数は続行されます。それ以外の場合は、エラーが返されます。

したがって、 a := b() -> handlerは次と同等です。

a, err := b()
if err != nil {
  if herr := handler(err); herr != nil {
    return herr
  }
}

さて、ショートカットとして、 a := b() -> throwの略であるtryビルトイン（またはキーワードまたは?=演算子など）をサポートできるので、次のように書くことができます。

func() error {
  a, b := try(f1())
  c, d := try(f2())
  e, f := try(f3())
  ...
  return nil
}() -> panic // or throw/fail/whatever

個人的には、 ?=演算子は、tryキーワード/組み込みよりも読みやすいと思います。

func() error {
  a, b ?= f1()
  c, d ?= f2()
  e, f ?= f3()
  ...
  return nil
}() -> panic

注：ここでは、呼び出し元にエラーを返すビルトインのプレースホルダーとしてthrowを使用しています。

私は一般的に賛成であり、彼らが向かっている方法が好きなので、これまでのところエラー処理の提案についてコメントしていません。 提案で定義されたtry関数と@thepuddsによって提案されたtryステートメントはどちらも、言語への合理的な追加であるように思われます。 Goチームが思いついたものは何でも良いものになると私は確信しています。

提案でtryがどのように定義されているか、そしてそれが将来の拡張にどのように影響するかについて、私がマイナーな問題と見なしていることを取り上げたいと思います。

Tryは、可変数の引数を取る関数として定義されます。

func try(t1 T1, t2 T2, … tn Tn, te error) (T1, T2, … Tn)

関数呼び出しの結果をtry(f())のようにtryに渡すことは、Goでの複数の戻り値の動作方法により、暗黙的に機能します。

私が提案を読んだところ、次のスニペットは有効であり、意味的に同等です。

a, b = try(f())
//
u, v, err := f()
a, b = try(u, v, err)

この提案はまた、追加の引数でtryを拡張する可能性を高めます。

何らかの形で明示的に提供されたエラーハンドラー関数、またはその他の追加パラメーターを使用するのが良い考えであると将来的に判断した場合、その追加の引数をtry呼び出しに渡すことは簡単に可能です。

ハンドラー引数を追加するとします。 引数リストの最初または最後に配置できます。

var h handler
a, b = try(h, f())
// or
a, b = try(f(), h)

（上記のセマンティクスを前提として） tryは、明示的なハンドラー引数とハンドラーを返す関数を区別できないため、最初に配置しても機能しません。

func f() (handler, error) { ... }
func g() (error) { ... }
try(f())
try(h, g())

それを最後に置くことはおそらくうまくいくでしょう、しかしそれからtryは引数リストの始めにvarargsパラメータを持つ唯一の関数であるとして言語でユニークでしょう。

これらの問題はどちらも目を見張るものではありませんが、 tryが他の言語と矛盾していると感じさせるため、 tryが将来拡張しやすいかどうかはわかりません。提案は述べています。

@魔法の

ハンドラーを持つことは強力です、おそらく：
私はあなたがすでにhを宣言しました、

あなたはできる

var h handler
a, b, h = f()

また

a, b, h.err = f()

関数のような場合：

h:= handler(err error){
 log(...)
 return ....
} 

それから、

a, b, h(err) = f()

すべてがハンドラーを呼び出すことができます
また、提案されているように、エラー（conitnue / break / return）を返すか、キャプチャするだけのハンドラーを「選択」することもできます。

したがって、varargsの問題はなくなりました。

@brynbellomyのelse提案の1つの代替案：

a, b := try f() else err { /* handle error */ }

elseの直後に装飾機能をサポートすることもできます。

decorate := func(err error) error { return fmt.Errorf("foo failed: %v", err) }

try a, b := f() else decorate
try c, d := g() else decorate

そして多分またいくつかのユーティリティは次の線に沿って何かを機能させます：

decorate := fmt.DecorateErrorf("foo failed")

装飾関数は署名func(error) errorを持つことができ、tryが試行されている関連関数から戻る直前に、エラーが存在する場合にtryによって呼び出されます。

これは、提案文書の以前の「設計の反復」の1つと精神的に似ています。

f := try(os.Open(filename), handler)              // handler will be called in error case

より複雑なものやステートメントのブロックが必要な場合は、代わりにifを使用できます（今日と同じように）。

そうは言っても、 https： //github.com/golang/go/issues/32437#issuecomment-500949780の@brynbellomyの例に示されているtryの視覚的な配置には素晴らしい点があります。

そのアプローチが均一なエラー装飾のために選択された場合、これはすべてdeferで機能する可能性があります（または理論的には装飾関数を登録する別の形式がある可能性がありますが、それは別のポイントです）。

いずれにせよ、ここで何が最善かはわかりませんが、別のオプションを明示的にしたいと思いました。

これが@brynbellomyの例で、 try関数で書き直され、$ varブロックを使用して、 @ thepuddsがhttps://github.com/golang/go/issuesで指摘した適切な配置を保持しています。

package main

import (
    "fmt"
    "time"
)

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    var (
        headRef          = try(r.Head())
        parentObjOne     = try(headRef.Peel(git.ObjectCommit))
        parentObjTwo     = try(remoteBranch.Reference.Peel(git.ObjectCommit))
        parentCommitOne  = try(parentObjOne.AsCommit())
        parentCommitTwo  = try(parentObjTwo.AsCommit())
        treeOid          = try(index.WriteTree())
        tree             = try(r.LookupTree(treeOid))
        remoteBranchName = try(remoteBranch.Name())
    )

    userName, userEmail, err := r.UserIdentityFromConfig()
    if err != nil {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    _, err = r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    return err
}

それはtryステートメントバージョンと同じくらい簡潔であり、私は同じように読みやすいと主張します。 tryは式であるため、読みやすさを犠牲にして、これらの中間変数のいくつかを削除できますが、それは他の何よりもスタイルの問題のようです。

ただし、 tryがvarブロックでどのように機能するかという問題が発生します。 varの各行は、いつ割り当てられるかの順序に関しては、ブロック全体が単一のステートメントではなく、個別のステートメントとしてカウントされると想定しています。

「try」の提案で、単純なステートメントカウントを使用してテストカバレッジ統計を概算するcmd / coverなどのツールの結果を明示的に呼び出すとよいでしょう。 目に見えないエラー制御フローが過少カウントになるのではないかと心配しています。

@thepudds

a、b：= f（）を試してください。

おそらく私の脳細胞の火傷が深すぎるかもしれませんが、これは私にあまりにも多くの打撃を与えます

try a, b := f() ;catch(decorate)

と滑りやすい坂道へ

a, b := f()
catch(decorate)

私はあなたがそれがどこをリードしているのかを見ることができると思います、そして私にとっては比較します

    try headRef := r.Head()
    try parentObjOne := headRef.Peel(git.ObjectCommit)
    try parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    try parentCommitOne := parentObjOne.AsCommit()
    try parentCommitTwo := parentObjTwo.AsCommit()
    try treeOid := index.WriteTree()
    try tree := r.LookupTree(treeOid)
    try remoteBranchName := remoteBranch.Name()

と

    try ( 
    headRef := r.Head()
    parentObjOne := headRef.Peel(git.ObjectCommit)
    parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    parentCommitOne := parentObjOne.AsCommit()
    parentCommitTwo := parentObjTwo.AsCommit()
    treeOid := index.WriteTree()
    tree := r.LookupTree(treeOid)
    remoteBranchName := remoteBranch.Name()
    )

（または最後のキャッチ）
2つ目はより読みやすくなっていますが、以下の関数が2つの変数を返すという事実を強調しており、魔法のように1つを破棄して、「魔法の戻りエラー」に収集します。

    try(err) ( 
    headRef := r.Head()
    parentObjOne := headRef.Peel(git.ObjectCommit)
    parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    parentCommitOne := parentObjOne.AsCommit()
    parentCommitTwo := parentObjTwo.AsCommit()
    treeOid := index.WriteTree()
    tree := r.LookupTree(treeOid)
    remoteBranchName := remoteBranch.Name()
    ); err!=nil {
      //handle the err
    }

少なくとも明示的に変数を返すように設定し、必要なときにいつでも関数内で処理できるようにします。

他の誰も明示的に言及していないので、特定のコメントを挿入するだけです。具体的には、次の1行の書式設定または任意のバリアントをサポートするようにgofmtを変更することについてです。

if f() { return nil, err }

いいえ、お願いします。 単一行ifが必要な場合は、単一行ifを作成してください。例：

if f() then return nil, err

ただし、中かっこを使用するコードを読みやすくするための改行を削除する構文サラダを使用しないでください。

議論の最中に忘れられたかもしれないいくつかのことを強調したいと思います。

1）この提案の要点は、一般的なエラー処理をバックグラウンドにフェードインさせることです。エラー処理がコードを支配するべきではありません。 しかし、それでも明示的である必要があります。 エラー処理をさらに際立たせる代替案のいずれも、要点を欠いています。 @ianlancetaylorがすでに述べたように、これらの代替案が定型文の量を大幅に削減しない場合は、 ifステートメントをそのまま使用できます。 （そして、定型文を減らす要求は、Goコミュニティのあなたから来ています。）

2）現在の提案に関する不満の1つは、それにアクセスするためにエラー結果に名前を付ける必要があることです。 代替案が追加の構文、つまり、その変数に明示的に名前を付けるためのより多くの定型文（ ... else err { ... }など）を導入しない限り、代替案でも同じ問題が発生します。 しかし、興味深いのは、エラーの装飾を気にせず、結果パラメーターに名前を付けないが、ある種の明示的なハンドラーがあるために明示的なreturnが必要な場合、そのreturnステートメントこの場合、ネイキッドリターンは許可されていないため、すべての（通常はゼロの）結果値を列挙する必要があります。 特に、関数がエラーを装飾せずに多くのエラーリターンを実行する場合、それらの明示的なリターン（ return nil, errなど）はボイラープレートに追加されます。 現在の提案、および明示的なreturnを必要としない代替案は、それを排除します。 一方、エラーを装飾したい場合、現在の提案では、エラー値にアクセスするために、エラー結果（および他のすべての結果）に名前を付ける必要があります。 これには、明示的なハンドラーでネイキッドリターンを使用でき、他のすべての結果値を繰り返す必要がないという優れた副作用があります。 （裸のリターンには強い感情があることは知っていますが、実際には、エラーの結果だけを気にする場合、他のすべての（通常はゼロの）結果値を列挙する必要があるのは本当に厄介です-それは何も追加しませんコードの理解）。 つまり、エラー結果に名前を付けて装飾できるようにすることで、ボイラープレートをさらに減らすことができます。

@magicalこれを指摘してくれてありがとう。 私は提案を投稿した直後に同じことに気づきました（しかし、それ以上混乱を引き起こさないようにそれを持ち出しませんでした）。 正解ですが、 tryは拡張できませんでした。 幸いなことに、修正は簡単です。 （たまたま、以前の内部提案にはこの問題はありませんでした。公開用に最終バージョンを書き直し、既存のパラメーター受け渡しルールにより厳密に一致するようにtryを単純化しようとしたときに導入されました。これは、すばらしいように思えました。 -しかし、結局のところ、欠陥があり、ほとんど役に立たない- try(a, b, c, handle)を記述できることには利点があります。）

tryの以前のバージョンでは、大まかに次のように定義されていました。 try(expr, handler)は、引数として1つ（または2つ）の式を取ります。最初の式は複数値である可能性があります（式が関数呼び出し）。 その（おそらく複数値の）式の最後の値はerror型である必要があり、その値はnilに対してテストされます。 （など-あなたが想像できる残りの部分）。

とにかく、要点は、 try構文的に1つ、またはおそらく2つの式のみを受け入れるということです。 （ただし、 tryのセマンティクスを説明するのは少し難しいです。）結果は、次のようなコードになります。

a, b := try(u, v, err)

もう許可されないでしょう。 しかし、そもそもこれを機能させる理由はほとんどありません。ほとんどの場合（ aとbが結果に名前が付けられていない限り）、このコードは、何らかの理由で重要な場合は、簡単に次のように書き直すことができます。

a, b := u, v  // we don't care if the assignment happens in case of an error
try(err)

（または、必要に応じてifステートメントを使用します）。 しかし、繰り返しますが、これは重要ではないようです。

この場合、ネイキッドリターンは許可されないため、そのreturnステートメントはすべての（通常はゼロの）結果値を列挙する必要があります。

裸での帰りは許可されていませんが、試してみてください。 try（関数またはステートメントとして）について私が気に入っていることの1つは、エラーを返すときにエラー以外の値を設定する方法を考える必要がないことです。tryを使用するだけです。

@griesemer説明ありがとうございます。 それが私も得た結論です。

ステートメントとしてのtryに関する簡単なコメント： https： //github.com/golang/go/issues/32437#issuecomment -501035322の例でわかるように、 tryはledeを埋めます。 コードは一連のtryステートメントになり、コードが実際に行っていることを覆い隠します。

既存のコードは、 if err != nilブロックの後に新しく宣言されたエラー変数を再利用する場合があります。 変数を非表示にするとそれが壊れ、名前付きの戻り変数を関数のシグネチャに追加しても、常に修正されるとは限りません。

エラー宣言/割り当てをそのままにして、1行のエラー処理stmtを見つけるのが最善かもしれません。

err := f() // followed by one of

on err, return err            // any type can be tested for non-zero
on err, return fmt.Errorf(...)
on err, fmt.Println(err)      // doesn't stop the function
on err, hname err             // handler invocation without parens
on err, ignore err            // optional ignore handler logs error if defined

if err, return err            // alternatively, use if

handle hname(err error, clr caller) { // type caller has results of runtime.Caller()
   if err == io.Bad { return err }
   fmt.Println(clr.name, err)
}

try部分式はパニックになる可能性があります。つまり、エラーは予期されません。 その変種はエラーを無視する可能性があります。

f(try g()) // panic on error
f(try_ g()) // ignore any error

この提案の要点は、一般的なエラー処理をバックグラウンドにフェードインさせることです。エラー処理がコードを支配するべきではありません。 しかし、それでも明示的である必要があります。

コメントにtryをステートメントとしてリストするというアイデアが好きです。 明示的でありながら（固定長であるため）簡単に光沢を出すことができますが、混雑した線で隠すことができるため（常に同じ場所にあるため）簡単に光沢を出すことはできません。 前述のようにdefer fmt.HandleErrorf(...)と組み合わせることもできますが、エラーをラップするために名前付きパラメーターを悪用するという落とし穴があります（これは、私にはまだ巧妙なハックのようです。巧妙なハックは悪いです）。

式としてtryが気に入らなかった理由の1つは、簡単に理解できないか、簡単に理解できないことです。 次の2つの例を見てください。

式として試してください

// Too hidden, it's in a crowded function with many symbols that complicate the function.

f, err := os.OpenFile(try(FileName()), os.O_APPEND|os.O_WRONLY, 0600)

// Not easy enough, the word "try" already increases horizontal complexity, and it
// being an expression only encourages more horizontal complexity.
// If this code weren't collapsed to multiple lines, it would be extremely
// hard to read and unclear as to what's executing when.

fullContents := try(io.CopyN(
    os.Stdout,
    try(net.Dial("tcp", "localhost:"+try(buf.ReadString("\n"))),
    try(strconv.Atoi(try(buf.ReadString("\n")))),
))

ステートメントとして試してください

// easy to see while still not being too verbose

try name := FileName()
os.OpenFile(name, os.O_APPEND|os.O_WRONLY, 0600)

// does not allow for clever one-liners, code remains much more readable.
// also, the code reads in sequence from top-to-bottom.

try port := r.ReadString("\n")
try lengthStr := r.ReadString("\n")
try length := strconv.Atoi(lengthStr)

try con := net.Dial("tcp", "localhost:"+port)
try io.CopyN(os.Stdout, con, length)

要点

このコードは間違いなく考案されたものです、私は認めます。 しかし、私が得ているのは、一般に、式としてのtryは次の場合にはうまく機能しないということです。

1. エラーチェックをあまり必要としない混雑した表現の真ん中
2. 多くのエラーチェックを必要とする比較的単純な複数行のステートメント

ただし、 @ ianlancetaylorに同意します。各行をtryで始めると、各ステートメントの重要な部分（定義されている変数または実行されている関数）の邪魔になるようです。 ただし、同じ場所にあり、幅が固定されているため、気づきながら光沢を出すのがはるかに簡単だと思います。 しかし、人の目は違います。

また、コードで巧妙なワンライナーを奨励することは、一般的には悪い考えだと思います。 最初の例のように強力なワンライナーを作成できたことに驚いています。これは、多くのことを実行しているため、独自の機能全体に値するスニペットですが、折りたたんでいない場合は1行に収まります。読みやすさのために複数に。 オールインワンライン：

fullContents := try(io.CopyN(os.Stdout, try(net.Dial("tcp", "localhost:"+try(r.ReadString("\n"))), try(strconv.Atoi(try(r.ReadString("\n"))))))

*bufio.Readerからポートを読み取り、TCP接続を開始し、同じ*bufio.Readerで指定されたバイト数をstdoutにコピーします。 すべてエラー処理付き。 このような厳密なコーディング規則を持つ言語の場合、これは実際には許可されるべきではないと思います。 ただし、 gofmtがこれに役立つと思います。

このような厳密なコーディング規則を持つ言語の場合、これは実際には許可されるべきではないと思います。

Goで忌まわしいコードを書くことは可能です。 それをひどくフォーマットすることさえ可能です。 それに対して強い規範とツールがあります。 Goにもgotoがあります。

コードレビュー中に、複雑な式を有用な中間名を持つ複数のステートメントに分割するように人々に依頼することがあります。 同じ理由で、深くネストされたtryに対しても同様のことを行います。

つまり、言語を歪めることを犠牲にして、悪いコードを非合法化するために一生懸命努力しないでください。 コードをクリーンに保つための他のメカニズムがあり、基本的にケースバイケースで人間の判断を伴うものに適しています。