私はこれを2番目にします。 すべてのエラーを返す前に装飾することで、人間が読める形式のドキュメントをソースに追加する方法（通常、エラーを「[これらのコード行で行っていること]：[前のエラー]」としてフォーマットできませんでした）とユーザーに非常に気に入っています。読み取りエラー。

この方法で生成されたエラーは非常に有益であり、スタックトレースよりもはるかに読みやすくなっています。 スタックトレースを含む印刷されたエラーは、通常、ソースにアクセスする準備ができており（管理者はそのようなアクセス権を持っていない可能性があります）、実際にコード内の方法を知っていることを前提としています。

コンテキストやトレースの形式がないエラー（裸の文字列「EOF」）はまったく役に立ちません。 裸のエラーを簡単に返すことができるショートカットがあると、Goプログラムは多くの役に立たないエラーを出力するようになると思います。

どちらかといえば、おそらく新しい獣医とリントのルールを使用して、コンテキストでエラーを装飾することをプッシュしてサポートする必要があります。

明示的なエラーチェックも気に入っています。 tryは紛らわしく、暗黙の戻りは奇妙です。

エラーを再考する代わりに、これらのチェックを短くするための別のアプローチを試すことができると思います。

これは私が必ずしも同意しない例です：

value, err := foo()
return err if err != nil

これにより、より短いが明示的なアプローチが可能になります。 そして、それはコンテキストを追加することを可能にするでしょう！

とは言うものの、インラインifはRubyのものであり、あまりゴイッシュな感じはしませんが、これは単なるブレインストーミングです。 多分私たちは何か他のものを見つけます。

編集：私はここにこれに関する提案を追加しました： https ：

物事を行う方法は1つだけでなければなりません

[...]そのままにしてみませんか？

私たちは皆、これに対する答えを知っていると言っても過言ではないと思います。 心からわからない場合は、さまざまな提案の1つを読んで答えを見つけるだけです。

IMO、ここでは詳細が少なすぎて焦点を絞った議論をすることができず（つまり、提案として適格ではないと思います）、すぐにサークルジャークとコードを読みにくくするアイデアでいっぱいの別の自転車小屋に変わります。

これだけ。

間違いなく、この明示的なエラー処理のためにGoに参加しました。 これは、多くの言語が使用する暗黙のtry-catchと、ユーザーに返され明示的に処理されることを好むOptionやMaybeなどの関数タイプの間のどこかにあります。

新しい構成が本当にこれを解決するかどうかはわかりません。 if err := nilをこのようなヘルパー関数でラップすると、少し役立つかもしれません（私のさびたGoを許してください）：

func handleErr(err error, cb func(error)) {
        if err := nil {
                cb(err)
        }
}

しかし、このヘルパー関数の一般的な有用性を低下させる問題は、別のトピックである型システムです。

私はこれを2番目にします。 if err != nil { return err }は、コードベースのコードの一部ではありません。 したがって、「マクロ」を試してみてもまったく意味がありません。 コンテキストを説明するメッセージとともに、ラップされたエラーのみを返します。

異なる種類のエラーを区別するために異なるエラーメッセージを返したいので、deferを介してコンテキストを追加することも意味がありません。 ただし、 try(fn(), "my error message: %w")が役立つ場合があります。 ただし、それでも、行の長さが短いため、 if err != nil構造の方が望ましい場合があります。

率直に言って、 try提供する暗黙のリターンは必要ありません。 ジェネリックスがある場合は、代わりにモナド風の動作を使用するソリューションをお勧めします。

type Result<T> interface {
  Expect(err error) T
  OrElse(defaultValue T) T
}

func From<T>(value T, err error) Result<T> { ... }

私にとって、これは現在提案されているビルトインよりもはるかにクリーンですが、返されるメソッド（値、エラー）と結果が急増するため、上記にさらに変更を加える必要があります

エラーを明示的に装飾する方法がない現在のtry提案は、私のニーズを満たしていません。 私はそれを使うことを想像することはできません。 率直に言って、それはcode_smellと呼ばれることもあります。

間違った問題を解決しようとしているため、変更しても意味がない場合があります。

私たちが精通しているコードはエラー処理ではありません。

if err != nil {
  return err
}

これはエラーnil処理です。 このパターンのどの時点でも、エラーの値は処理されません。

これを別の言語、Rubyでデモンストレーションする場合。

begin
 some_method_that_raises_an_error
rescue => e # catch any exception
  retry e        # throw it up again
end

これは、golangコードと同じ動作を中継します。 例外が発生したことを検出し、それを再発生させたとき。 スタックに投げるだけです。

golangでは、 returnです。

実際の_エラー処理_はどこで発生していますか？

私たちは皆、このパターンの失敗について同様の経験をしました。 たとえば、 file not foundエラーを受信し、このエラーの元の_thrower_をトレースするのに長い時間を費やします。

これが、 try提案（およびその他）に誤りがあると私が信じる理由です。 実際にエラーを処理するための適切なパターンはありません。

実際にエラーを検査するためのerr.Error()文字列チェック、型アサーションなどを確認しました。
この不一致のパターンが必要です。 xerrsがこれを解決しているように感じますが、まだ完全ではありません。

err！= nilチェックをそのまま維持することをサポートします。

かなり大きなGoコードベースを掘り下げるたびに、ボイラープレートの一部を減らす方法を自問します。 私はいつも戻ってきます：

• これらのコードパスは、何らかの形で存在します。
• コードパスを非表示にする必要がない場合でも、コードパスを非表示にする機会をユーザーに与えると、デフォルトの動作になります（言語の使用の難しさを行数で測定しているようです）。
• デフォルトの動作でコードパスが非表示になっている場合は、新しい「クリーンアップがない」バグを探しています。
• 返されるエラーの意味とパターンは十分に多様であるため、この提案では認識された問題の一部しかキャプチャされません。
• 一部だけがキャプチャされた場合、私たちは確かにたくさんの解決策を得るでしょう
• たくさんの解決策があると、それらをロールアップするためのユースケースの適応魔法を持ちたいという誘惑が生まれます。
• これが実際に問題であった場合、人々は自由に独自の簡単な解決策を作成したり、大量に採用されたパターンを使用したりできます。 私はそのようなものを見たことがありません。 たぶん私は十分に一生懸命に見えていません。

課題トラッカーは多くのことに役立ちますが、役に立たないことの1つは、複雑なトピックの詳細な説明です。 課題トラッカーはスレッド化を提供せず、特定のメッセージへの返信は厄介です。 ここには実際の提案はなく、他の提案への回答に過ぎないので、この議論をgolang-nutsメーリングリストに持ち込むことを強くお勧めします。

可能であれば、これが答えだと思います。 この新しいエラー提案は、言語の目標と直接矛盾しています。

私がgolangを愛する理由は、その単純さと制御フローの明確な使用のためです。 私がJavaについて最も軽蔑していることの1つは、trythrowコンストラクトです。 それはとても嫌です。 それはひどいエラー処理を助長します。 コールスタックに例外を送信することは、制御フローを処理するための恐ろしくて嫌な方法です。 さらに、自己文書化して各エラー状況を明示的に処理するのではなく、すべてを巨大なチェックでラップして1日と呼ぶことをお勧めします。

err！= nilが適切なエラー処理を促進し、自己文書化であり、特定のケースに関する適切な文書化を促進する場合、正直なところ、これは私がgoで最も気に入っていることの1つです。 この新しい制御フローの割り込みを、乱雑でややあいまいな戻り値とパラメーターを使用して作成し、セマンティクスを混乱させることは、私が愛するようになった言語の精神ではありません。

冗長性は悪いことではありません。 不必要な冗長性はありますが、goのエラー処理は不要ではないと私は主張します。 それは言語の魅力の一部です。

これ以上同意できませんでした。 明示的なエラー処理は、IMO言語の最も優れた機能の1つです。 気になる人はまだ慣れていない気がします。

問題が分かれているのは良くありませんが、今回は2つの意見が1つの意見にまとめられていると思います。

1. 新しい構文は好きではありません（tryまたは新しいif-err構文）
2. とにかく、新しい構文を追加したくありません

GitHubの投票アイコンは2番目を解釈できません。

goでの明示的なエラー処理は、私がgolangを愛する理由の1つです。 なぜgo開発者が他の方法でそれを望んでいるのか理解できません。 新しい構文を追加するという提案は、ほとんどの場合、他の言語で使用されている構文を快適に使用できる人々からのものだと思います。 慣れるまで少し時間がかかるかもしれませんが、慣れれば完璧に動作します。

私は＃32811を書き、この提案をもっと支持します...エラー処理はそのままにしておきたいです。 この提案に対する絵文字の反応は多くを語っていると思います。

私は個人的に、エラー処理をそのままにしておくことに同意します。 Goについて私が気に入っていることの1つは、言語が最小限であり、一般的に言えば、物事を行う1つの方法があることです。 エラー処理用の新しい構文を追加することで、コードのx％が現在のメソッドを使用し、y％が新しいメソッドを使用する世界を作成します。 これは、すでに説明した他の問題の中でも、一貫性のないコードベースを作成します。 個人的には、既存の構文が十分/十分であると考えているため、新しいエラー処理構文の価値はトレードオフの価値があるとは思いません。

Golangを初めて使用する人として、この言語について私が新鮮に感じることの1つは、明示的なエラー処理です。 私はJava、Ruby、Python、Nodeでかなり重く働いてきましたが、エラーの処理はGoよりもはるかに面倒です。 エラーをより曖昧にする言語構造によって暗示されるよりも、エラーの明確な「パス」を見たいと思います。

ˋreturn ... if ... ˋ @ andreyneringからの提案は実際にはかなり賢い私見です。 ボイラープレート（ワンライナー）を削減している間、コードを明示的に保ちます（隠れた制御フローの中断はありません）。 。

同意します。 if err != nilはそのままにしておきます。

私は現在のフォーマットを好みます。 明確で教えやすいパターンです。 新しいエンジニアをスピードアップさせるのは簡単です。彼らは1つの単純なパターンを学び、それを繰り返すことができるからです。 また、少なくとも現在のコンテキストでエラーを考慮するようにユーザーに求め、少なくともエンジニアがここでエラーが発生する可能性があることを認識していることを確認します。私は何をすべきかを考える必要があります。

私は＃32804を書きましたが、物事が変わらないことを望んでいます。 コードが長い場合、それは多くのことを行うためです。 エラー処理コードがたくさんある場合、それはすべてのケースをうまく処理しているためです。

物を追加するためだけに物を追加しないでください。

エラー処理のシンプルさをそのまま楽しんでいます。

Expectは、を除いて単なるアナグラムであり、私はそれを使用したくありません。 これを始めてくれてありがとう。

私の聖杯を変えないでください。

より合理化されたエラー処理を要求する圧倒的なコミュニティフィードバックがありました（年次調査から）。 Goチームは現在その問題に取り組んでいます。

@icholyもちろんですが、現在の提案には

1つの不満はそれを入力しなければならないことでしたが、事実上すべてのエディターにはコードスニペットを挿入するためのショートカットがあるので、それは実際には大したことではありません。 おそらく、1.0より前からGoを使用したのは私自身の経験ですが、私はたまたまシンプルさが好きで、冗長性を気にしません。

@kevineaton tryは複雑だと思いますか？

私はこれに完全に同意します。 私は私たちが何かをする必要があると個人的にさえ確信していません-私はif err != nilチェックが一見ぎこちなく見えることに同意しますが、実際に問題を解決する提案されたものを見たことがありません。に人気があります。

@icholy Goの前にJavaとPythonを10年間書いた後、そうなる可能性があると思います。 ポケモンの例外キャッチ、または複数の例外のキャッチチェーンに遭遇したと思います。そうでなければ、さらに多くのオーバーヘッドと定型文が導入されます。 エラー処理を回避できれば、そのスタイルのエラー処理に戻ることはありません。ほとんどの場合、特に教えるときに頭痛や混乱を招くからです。 私はまた、ソフトウェアアーキテクトとしての日々の仕事に加えて、コンピューターサイエンスを教えているので、新しい開発者を教えたり、指導したりすることに偏っています。 私はGoを選択します。これは、より複雑で微妙なエラー処理よりも、単純なエラー処理です。

課題トラッカーは多くのことに役立ちますが、役に立たないことの1つは、複雑なトピックの詳細な説明です。

それは真実ではありません。 しかし、ここにあります。

if err != nil tryが追加されても、 if err != nilは消えません。 tryは、エラー転送が重いか、1つの遅延エラーハンドラーで多くの異なるエラーを簡単にまとめることができるコードパスにある程度の明確さを追加すると思います。 。 try 、空のif-err-return-err束よりもはるかに多くのエラーを処理しないように促す方法がよくわかりません。 tryが存在するかどうかに関係なく、実際にエラーを処理することを無視するのは簡単です。 tryは、それを使用しているコードが読みやすいように見えるので、エラー処理の最良の提案の1つだと思います。

私の一方的な2セント、それはあまり「行く」ように感じません。 それはあまりにも魔法であり、明示的なものよりも暗黙的な構成を採用します。

GoFAQから

Goに？：演算子がないのはなぜですか？
_Goには3項テスト操作はありません。 同じ結果を得るには、以下を使用できます。_

if expr {
   n = trueVal
} else {
    n = falseVal
}

？：がGoにない理由は、言語の設計者が、操作が頻繁に使用されて、不可解に複雑な式を作成するのを見ていたためです。 if-else形式は、長くなりますが、間違いなく明確です。 言語に必要な条件制御フロー構造は1つだけです。

@ianlancetaylor

課題トラッカーは多くのことに役立ちますが、役に立たないことの1つは、複雑なトピックの詳細な説明です。 課題トラッカーはスレッド化を提供せず、特定のメッセージへの返信は厄介です。 ここには実際の提案はなく、他の提案への回答に過ぎないので、この議論をgolang-nutsメーリングリストに持ち込むことを強くお勧めします。

特定のメッセージに返信できます。 私はあなたに返信しました。 :)

ここには実際の提案はないので、他の提案への返答だけです。

私への提案は、変化の呼びかけを意味します。 この特定の問題は反変化です。 エラー処理を変更しないという提案を作成することを提案しますか？ 提案体制は素晴らしいと思いますが、現状は過小評価されています。

JavaとPythonの作成に10年を費やした後、ソフトウェアアーキテクトとしての日々の仕事に加えて、コンピューターサイエンスも教えています。

@kevineatonあなたはあなた自身のディックを吸うことを

この問題は、基本的に誰でも簡単に提案に賛成または反対票を投じることができる半公式の場所での長期にわたる世論調査として機能します。

if err != nilを削除するために言語を変更しないことは、基本的に追加の詳細を必要としない完全に大げさな提案です。 何が問題なのかわかりません。 いいえ、それはひどく長くて、しゃがむのが難しい神ではありません。 それはそれを間違ったり、悪くしたり、不十分にしたりするものではありません。

+1、これ以上良いことはないにしても、本当に良いスタックトレース情報（フレームダンスのものなし）になるでしょう、 x/errorsすでにこれを達成していると思いますが、近い将来、マーキングのような迅速なものが大好きですfuncは、 error + tryキーワードを返すthrowsキーワードを使用して、エラー変数のシャドウイング（私は個人的に嫌いです）を防ぎます。

func a() (int) throws {
  throw &someError{}
}

anInt, err := try a()

@icholyそれは信じられないほど求められてい

現在のエラー処理は、人為的エラーが発生しやすいものです。 現時点でerrをチェックするのを忘れるのは簡単です。 スコープ内にすでにチェックがある場合（そしてほとんどの場合）、コンパイラーはunused variable終了しません。 エラー処理は厳密である必要があります-エラーを_するか、チェックします-レッグシュートは不可能です。

@kevineaton tryは複雑だと思いますか？

tryはコードの臭いです。 これにより、1つの場所だけでなく、コードのブロック全体にインデントが強制されます。 さらに、例外処理の「バブルアップ」の性質により、コードおよび複数の出口点で事実上の非決定論的な動作が発生します。

try代わりに複数の戻り値を使用することの利点は、関数が完了したときにチェックする値が1つと、関数からの終了点が1つあることです（もちろん、ガードステートメントやその他の明示的な戻り値を使用する場合を除く）。

tryブロックは、複数のリターンというクソの目的全体を打ち負かします。

@fillestコードが少し読みにくくなりますが、これは安全性/明示的なエラー処理の観点から付加価値になると思います。 Goでエラーを処理する方法の当初の目標を振り返ると、明示的な善の精神を追求しながら、引用するバグのクラスを回避するための良い反復になると思います。

現在のエラー処理は、人為的エラーが発生しやすいものです。 現時点でエラーをチェックするのを忘れるのは簡単です。 スコープ内にすでにチェックがある場合（そしてほとんどの場合）、コンパイラーは未使用の変数で終了しません。 エラー処理は厳密である必要があります-エラーを_エラーまたはチェックします-レッグシュートは不可能である必要があります。

@fillest提案されたエラー処理の変更により、「レッグシューティング」が容易になり、エラーは遅延処理できるため、より顕著になります。

ジェネリックスの欠如、ボイラープレートの傾向、GC、リソース制限/アカウンティングの欠如、およびコンパイラーの機能を理解していないPHP初心者から生成されたワークロードのためにGoの使用をやめました。 Haskell、C＃などはエラー処理をかなりうまく解決しました... Go 2の提案は、以前のように明示的なケース処理があれば問題ないように見えます（不明）。

エラー処理はプログラミングの中心です。 ビジネスロジックのモデリング（複雑ですが）は、このロジックが生成する無効な条件に対応するよりも常に簡単です。 エラーを転送するだけでは、コードの臭いがします。 Goがこの動作を奨励しないが、エラー管理パターンを促進することを望みます。 初心者は、中央のエラー管理がいかに重要であるかを理解していないため、このすべてのエラー処理コードと混同されることがよくあります。

tryビルトインはエラーをラップして少しでも情報を追加するのに役立たないので、完全に同意します。

try書き換える前に：

_, err := doSomething()
if err != nil {
    return nil, errors.Wrap(err, "failed to do something")
}

_, err = doOtherThing()
if err != nil {
  return nil, errors.Wrap("failed to do the other thing")
}

try書き直した後の様子を想像してみてください。

try 、引数を括弧で囲むことにより、すでに1引数関数のように機能するため、エラーラッピングコードである2番目の引数を受け入れることができます。

try(extract_value(try(get_data(1), errors.Wrap(err, "failed to get data")), errors.Wrap(err, "failed to get data")))

err値を暗黙的に導入する必要がある場合（衛生的な方法で）。 次に、 tryが1引数関数として使用される場合、エラーは変更されずに返されます。

私は同意します、エラー処理を少し簡単にするかもしれない唯一の「シンタックスシュガー」は、関数から複数のリターンがあるときに次のようなことをさせてくれます...アンダースコアはリターンタイプが何であれデフォルト値になります

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

@sorenvonsarvortそれは

var errContext string 

defer func() {
  // err is a named return
  if err != nil {
    err = fmt.Errorf("%v: %w", errContext, err)
  }
}()

errContext = "failed to do something"
_ := try(doSomething())

errContext = "failed to do other thing"
_ := try(doOtherThing())

私の理解では、コードの特定のセクションが明確であれば、 if err != nil { ... }使用することもできます。

tryは他の場合に輝きます。 次のようなものを想像してみてください。

func trySomeComplexOp() (r result, err error) {
  a := try(step1())
  b := try(step2(a))
  c, d := try(step3(b))
  return try(lastStep(c, d)), nil
}

上記のコードのようなコードは、 if err != nilブロックを振りかける必要がある場合よりもはるかにクリーンになる可能性があります。 Goは「線形の読みやすさ」がすべてなので、 tryはその目的に向かってうまくいくと思います。

より合理化されたエラー処理を要求する圧倒的なコミュニティフィードバックがありました（年次調査から）。 Goチームは現在その問題に取り組んでいます。

これはボーカルのマイノリティであり、それらのかなりの部分がGoを使用していないに違いありません。

@sirkonその声明の根拠は何ですか？

@sorenvonsarvortそれは

上記のコードのようなコードは、 if err != nilブロックを振りかける必要がある場合よりもはるかにクリーンになる可能性があります。 Goは「線形の読みやすさ」がすべてなので、 tryはその目的に向かってうまくいくと思います。

ロシアでは、これを「экономиянаспичках」と呼んでいます。 意味を理解するためにグーグル翻訳を使用してください。

まだ読んでいないこのスレッドの人には、元のtryプロポーザルの問題に関するこのコメントを読むことをお勧めします。 一般的なエラーコンテキストのベストプラクティスと、それがtryどのように表現されるかについて説明します。

おそらく、Goコミュニティではエラーコンテキストが少し独断的になっていると思います。 私は個人的にこれに陥り、エラーを過度に文脈化して、非常に長く、反復的で、読みにくいメッセージをもたらしたことを知っています。 エラーをコンテキスト化するタイミングとしないタイミングに関しては、多くのニュアンスがあります。

tryは基本的にショートカットであり、ボイラープレートコードを減らすことが好きです。 ただし、エラーを追加情報でラップする機能は失われます。 ただし、次の変更で修正される可能性があります。

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

になります

f := try(os.Open(filename), "open data file")

もちろん、それ以上のことをする必要がある場合でも、 err != nilチェックを行う「完全な」方法は引き続き利用できます。

私はこれに同意しますが、最終的な意見を述べる前に、変更についてより多くの経験を積むというゴーチームからの要求を尊重します。

しかし、変更に関する私の予備的な経験は、それが本当に不必要であることを支持しているようです。 私はそれぞれ約1万行の2つの「現実世界」のプログラムを持っており、両方でわかります。 これは、どちらも常にエラーにコンテキストを追加するという事実によって簡単に説明されます。 Goには他にも小さな「おもちゃ」プログラムがあり、 tryhardは、そのうちの1つでtryを使用できたケースを1つ見つけましたが、それだけです。

他の人が私とは異なる方法でエラーを処理する可能性があることを認め、 tryを積極的に使用できる可能性を認めます。 tryhardソースコード自体には、 return err連続したケースがいくつかあります。これは、 tryを使用した場合、読みやすさがそれほど損なわれることはないと思います。 しかし、誤用は読みやすさに影響を与えるので、私は誤用を恐れています。 良い例がここにあります。 そして、何が良い使い方かを判断することは、まったく別の話になります。

また、自分でプログラムを実行しなくても、通常はgoコードを読み取ることができる方法が好きです。 これにより、特に他の言語で見た他のtryとは異なることを行うため、 tryが行う魔法を学ぶ必要があります。 これは、この言語を初めて使用する人にも当てはまります。これは、「必要な機能だけ」を備えていることでシンプルであることに誇りを持っている言語で学ばなければならないもう1つの機能です。

待って見てみましょう。 私はこの変更をもっと実験するつもりですが、それが私の立場を変えるとは確信していません。

より合理化されたエラー処理を要求する圧倒的なコミュニティフィードバックがありました（年次調査から）。 Goチームは現在その問題に取り組んでいます。

@icholy私が言ったように、私はエラーにコンテキストを追加するのが好きです。 その点で、私にとって「より合理化されたエラー処理」とは、そのコンテキストを提供し、そこから情報を取得するためのより良い方法を意味します。 たとえば、エラーに追加したすべてのコンテキストで、エラーの原因がタイムアウトであるかどうかを「コンテキスト」に尋ねるのは簡単なはずです。 しかし、そうではありません。 通常、 pkg/errorを使用するか、独自の「エラー構造」を作成するか、実装によっては文字列検索を実行できるメソッドを作成する必要があります。 せいぜいたまに1つのifを節約するものよりも、構造体やメソッド全体を作成することから私を救う何かを見たいと思います。 そして、以前に言われたように、この変更が基本的にエラーを実際に処理しないためのより便利な方法を提供しているとき、それを本当に「エラー処理」と呼ぶことができますか？

tryは複雑だと思いますか？

単独でtryは複雑ではありませんが、言語の変更は単独では考慮されません。 検討：

• 新しいビルトインのセマンティクスを学習することによる認知的負荷の増加
• if err != nil {return ... errors.Wrap() }を代わりに使用する必要がある場合に、 tryを使用すると読みやすさが低下するため、読みやすさが低下します。

エラーをチェックする簡単な方法よりも、単純さ（エラーをチェックする単一の方法を持つ）の方が重要であるという感情を上に繰り返します。

エラーを処理する方法は、そのグローバルステートメントを使用することではありませんか。これが無視されるものである場合、パニック状況はどのように処理されますか？ 他のプログラミングパラダイムが今日エラーを処理するので、より良いエラー処理をサポートしますが、無視しないでください

try提案に問題はありませんか？
古い動作を使用したい場合、または他の方法でエラーを処理する必要がある場合は、古い方法を再利用してみませんか？ try構文を使用している首を押す人は誰もいませんか？
try構文は単純で、定型コードを減らすための美しい方法ですが、なぜgopherがサディズムを愛しているのかわかりません。

ブロックが1行にとどまる場合、1つのステートメントが表示されるようにgofmtが変更された場合はどうなりますか？

そうすれば、ラップされたエラーを処理するのに、ほとんどの場合3行ではなく1行しかかからない可能性があります。 これにより、エラー処理によって占められる垂直方向のスペースが削減され、エラー処理が平均的な関数の垂直方向のスペースの半分以上を占めていないように見えます。

これがどのように見えるかです：

// we already have an err in scope
err = frub.Confozzle(foo, bar, baz)
if err != nil { return errors.Wrap(err, "confozzling didn't work") }

おそらく、Goコミュニティではエラーコンテキストが少し独断的になっていると思います。 私は個人的にこれに陥り、エラーを過度に文脈化して、非常に長く、反復的で、読みにくいメッセージをもたらしたことを知っています。 エラーをコンテキスト化するタイミングとしないタイミングに関しては、多くのニュアンスがあります。

エラーラッピングとスタックフレーム/エラー印刷のものは、はるかに簡単になります。 そのうちに良い解決策があると思いますが、今はそうではありません。個人的には、パラメトリック多型が解決するまで、より強力なgo2機能の導入を待ちたいと思います。これは、残りの機能を設計するときに役立つ可能性があるためです。

そのままにしておくことに完全に同意します。 少し冗長すぎますが、従うのはかなり簡単です。

減らすことができれば

if err := foo.x(a, b); err != nil {
    return err
}

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

if err := foo.z(c); err != nil {
    return err
}

のようなものに

if err := check foo.x(a, b), foo.y(), foo.z(c); err != nil {
    return err
}

イディオムをあまり変えなくてもいいかもしれません。

@henvicそれに関する問題は、3つのエラーを同じ方法で処理したいと想定していることだと思います。 Goを使用すると、各エラーを個別に処理する方法を考える必要があります。 個別のエラーチェックがあると、これが明確になります。 それらを1つに集約すると、開発者は認知的に戻って確認する必要があります。これらのエラーは_本当に_同じように処理する必要がありますか？ この提案では、明確さが失われ、キーストロークが数回少なくなるとエラーについて考える必要が生じたと思います。

@sanbornm 、あなたは正しいです。 同意します。

このcheckは、1つの戻り引数のみを取り、最初のゼロ以外の値（nullなど）で返すcheckNonZero演算子である可能性もあります。 しかし、曖昧すぎて、言語にさらに影響を与えることに加えて。 たとえば、io.EOFを期待している場合は、使用すべきではないというヒントが少しでも与えられます。 別の可能性は、おそらく、少なくとも最も一般的なケース（パイプから読み取るときのio.EOFなど）を知らせるためにgo vetを頼りにすることです...しかし、このアイデアは得意ではありませんすべて私に。

try提案に問題はありませんか？
古い動作を使用したい場合、または他の方法でエラーを処理する必要がある場合は、古い方法を再利用してみませんか？ try構文を使用している首を押す人は誰もいませんか？
try構文は単純で、定型コードを減らすための美しい方法ですが、なぜgopherがサディズムを愛しているのかわかりません。

私たちは皆、コミュニティに住んでいます。 私は毎日、他の人が書いたたくさんのコードを扱っています。 ですから、言語を変えても、使わなくても影響を受けます。

大規模なプロジェクトでは、最悪のログは、誰かが書いたことを忘れた関数によって生成されます。この関数は、「ポケモン」例外ハンドラーが実行するまで何もキャッチされなかった汎用new Exception()をスローしたライブラリを呼び出すライブラリを呼び出すライブラリを呼び出します。一般的なエラーをログに記録しました。 2番目に悪いものは同じですが、不可解な数百行のスタックトレースがあり、最終的に原因を突き止めることができると思います（幸い、 github.com/<us>/<ourproject>を検索するだけで、関連情報のほとんどが見つかりますが、時々たくさんあります）。 その名前にもかかわらず、「例外」は大きなJavaプロジェクトでは悲惨なほど例外的ではありません。

一方、冗長なコンテキストがたくさんある場合でも、重要なコンテキストをどこかに埋め込むことに熱心に取り組んでいる限り、 "narf: Error unpoiting the zort: foo: Unexpected bar in baz: {\"ork\": \"morpork\"}"ような単純なGoエラー文字列は（私の経験では）通常は非常に簡単に解釈できます。実際のエラー値。 重要なコンテキストが欠落していることが判明した場合、それは通常かなり明白です。 このような場合の「修正」は、コンテキストを追加して別のエラーを待機することであるため、完全ではありませんが、バランスをとると、スタックトレースをスクロールしたり、依存関係の依存関係に依存して「スロー」するよりも、これを優先します。 「または「発生」する正常なエラーメッセージ。 panic()という名前が、ほとんどのGo開発者が本質的に同じ言語機能を自由に展開することを妨げているように見えることを本当に感謝しています。 結局、 errorとpanic同じものにしないようにしましょう。

関数に12ほどの障害モードがあり、それらの大部分が同じエラーメッセージに値する状況に遭遇することがあります。 繰り返しは実際には気になりませんが、通常、私のチームには他の誰かが気になります。そのため、これらの一般的なエラーを処理するために、関数の開始時にクロージャを宣言することで妥協します。

func foo(a, b, c SomeArgType) (x, y, z SomeReturnType, err error) {
  handleError := func(handleErr error) (x, y, z SomeReturnType, err error) {
    log.WithFields(logrus.Fields{
      "package": "foo",
      "func": "foo",
      "arguments": map[string]SomeArgType{"a": a, "b": b, "c": c},
      "error": handleErr,
    }).Error("Error fooing the bar")
    return reasonable, default, values, handleErr
  }

  err := doABunchOfThings()
  if err != nil {
    return handleError(err)
  }
}

確かに、これはいくつかの点でまだ不完全な解決策です。 しかし、これを行うことで、将来の開発者が、制御フローがあまり飛び回ることなく、 fooがいつ何を返すかを非常に簡単に理解できるようになったことが気に入っています。

どういうわけか、この繰り返しの「問題」が、（私が通常見ているように）還元不可能な複雑なパッケージ内の少数の還元不可能な複雑な関数に限定されるのではなく、多数のパッケージ全体で非常に一般的である場合、プロジェクト全体の「ファンクター」を使用して同様の目的であり、（ため息）パラメトリック型の概念が言語に追加された場合、try / catchに依存することなく、エラー処理ファクトリファクトリの背後にさらに詳細を隠すことができます。

@thomasf

エラーラッピングとスタックフレーム/エラー印刷のものははるかに簡単になります

同意します。

個人的には、パラメトリック多型が解決するまで、より強力なgo2機能の導入を待ちたいと思います。これは、残りの機能を設計するときに役立つ可能性があるためです。

元のtry提案の何人かの人々は、ジェネリックを待つことについても議論しましたが、パラメトリック多型がtry提案をどのように変えるかは私にはわかりません。 すでに組み込まれているので、言語で表現できるものの制限に限定されません。

@icholy

より合理化されたエラー処理を要求する圧倒的なコミュニティフィードバックがありました（年次調査から）。 Goチームは現在その問題に取り組んでいます。

これに対応するためだけに。 英国のEU離脱を支持する過半数もありました。 確かに、EUは一般大衆が対応したいくつかの不利な点ももたらします。 しかし、すべての選択肢が提示された後は、EUにとどまるのは結局それほど悪くはないように思われました。

さて、これを政治化することは私の意図ではまったくなく、あなたは上記に同意しないかもしれません。 しかし、私が示したいのは、大多数が最初に何かを迷惑だと考えたとしても、すべての選択肢を検討した後でも、それが最善の解決策になる可能性があるということです。

私はエラー処理について強く意見を持っていませんが、それは物事をそのままにしておくための議論になる可能性があります。

プロフェッショナルなコーディング環境では、現在のエラー処理手法を利用して、トレースシステムに注釈を付け、ログを装飾します。 余談ですが、暗黙的な戻りは、エクスポートされたライブラリ関数でパニックを使用するのと似ており、フロー制御の即時の可読性を覆い隠します。

@icholy

より合理化されたエラー処理を要求する圧倒的なコミュニティフィードバックがありました（年次調査から）。 Goチームは現在その問題に取り組んでいます。

これに対応するためだけに。 英国のEU離脱を支持する過半数もありました。 確かに、EUは一般大衆が対応したいくつかの不利な点ももたらします。 しかし、すべての選択肢が提示された後は、EUにとどまるのは結局それほど悪くはないように思われました。

この人の主張を真剣に考える必要はありません。絵文字の数は、人々が一般的にtry提案を嫌い、一般的にこの「そのまま」の提案を好むことを示しています。

私の実践では、PSはメインドメイン（ネットワークサービス、CLIユーティリティ）でGoを嫌う大多数の人々がそれを使用したことさえありません。 だから私は彼らの意見を無視したいと思います。

try提案よりも優れた、物議を醸すことが少ないオプションが必要です。
急いで解決する緊急性は見当たらない。

@velovixトライ/キャッチエラーの「処理」よりもパラメトリックポリモーフィズムが嫌いだと思いますが、それが言語機能になった場合、別の組み込み言語機能の必要性を回避するいくつかの方法を見ることができました。

一つには、人々が繰り返したくないコードは、次のような定型文です。

foo, err := Foo()
if err != nil {
  log(err)
}
bar, err := Bar(foo)
if err != nil {
  log(err)
}
// ...

次に、パラメトリック関数、型推論、および_maybe_または_optional_スタイルのオブジェクトデザインパターンのいくつかの組み合わせは、奇妙な非線形制御フロー戦略に頼ることなく、ボイラープレートを簡単に（heh）削減します。

func<T> DoWithErrorLogging(f func(any...) (T, error), args... any) T {
  t, err := f(args...)
  if err != nil {
    log(err)
  }
  return t
}
// ...
foo := DoWithErrorLogging(Foo)
bar := DoWithErrorLogging(Bar, foo)

IMOこれはすべて、Go1よりもはるかに悪いでしょう。 しかし、この_plus_ try / catchキーワードをその言語で使用するよりはましです。

正直なところ...今のところ、Go2の私のお気に入りの「破壊的な」変更は、Go1の小さな不便をすべて修正するだけだと思います。たとえば、 net/httpデフォルトは、可変共有グローバル内にネストされた可変共有グローバルです（ Hashicorpのcleanhttp標準（基本的に）、または(*time.Timer).Reset()に、知っておく必要のsyscallパッケージ全体を作成します。 Go3は、その直後に、人々が成長させたい腫瘍が何であれ、リリースすることができます。 大小の重大な変更をすべて1つのリリースで行う必要がある理由がわかりません。

控えめに使用すると、 tryに賛成です。 人気のあるプロジェクトでは、tryを使用しても問題がないかどうかに関するガイドラインが追加され、小規模/新規/独身のプロジェクトでは、 tryが原因で、エラーが少なくなり、使用できなくなることがあると思います。

言語にtryを追加しても、それほどひどいことはないと思います。 人々の最悪の場合の恐れが根底にあることが証明された場合、その使用は眉をひそめるでしょう。 経験の浅い人は無差別に使用しますが、他の人は使用しません。 それは世界の終わりではありません。

tryが追加された場合、私はおそらくそれを使用するでしょう。 そのような場合は、エラーが返されますが、実際にエラーが発生する可能性は非常に低いと思います。コンテキストを追加しても意味がわからないので、そのままエラーを返します。 たとえば、1 TBであることがわかっているディスクを埋めるファイルシステムを作成したばかりの場合、1kbのファイルまたはディレクトリを作成するためのスペースがあることを確信できます。 それが失敗した場合、私はエラーを無視したくありません-それは他の場所のバグ、ハードウェア障害などを示している可能性があります。しかし、すべてのめちゃくちゃ-ありそうもないエラーに注釈を付けることに努力する価値はありません。

try（..）が、入力時に考えるために、コーダーのマインドスタックにもう1組の括弧/ブラケットを配置する方法が好きではありません。 そして、私が想像できる最も長い間！

したがって、これはより良いです：
値、エラー：= foo（）
err！= nilの場合はerrを返します

しかし、それでもこれは非常に一般的です。 だから私はこのようなsmtがどういうわけか可能であるかどうかを望みます：

値、エラーを確認してください：= foo（）

Goが読みやすい言語になりたい場合は、読みにくい、または理解しにくいと考える能力を最小限に抑える必要があります。

Goが適切なエラー処理を行いたい場合は、エラーがコールスタックを上るときに、エラーに追加のコンテキストを持たせるように促す必要があります。 エラーを処理するためにdeferを使用するという要件は、紛らわしいようです。 エラーハンドラにエラーがある場合はどうなりますか？ 延期はスタック順に実行されますが、ハンドラーを逆に宣言する必要がありますか？

ステートメントが単純で、ここにあいまいさの余地がほとんどない場合。 tryは、実際のエンジニアリングの問題ではなく、問題を解決しているように感じます。 私はこの提案が好きです。なぜなら、これらの複雑な提案のあらゆる側面を完全に理解することなく、サイレントマジョリティが最終的に発言できるからです。

@icholy礼儀正しくしてください。 Gopherの行動規範に注意してください： https ：

皆さん：上記の私のコメント（https://github.com/golang/go/issues/32825#issuecomment-506740412）に加えて、https：//golang.org/wiki/NoPlusOneに注意してください。 「同意する」または「同意しない」と言っても意味がありません。 代わりに絵文字ボタンを使用してください。 ありがとう。

@sanbornm

（私はメッセージに返信することが可能であることに同意します。それは厄介で不可能ではないと言いました。そして、このミニスレッドが他のコメントの猛吹雪で失われるという点で、スレッドについての私のポイントはまだ残っています。）

私への提案は、変化の呼びかけを意味します。 この特定の問題は反変化です。 エラー処理を変更しない提案を作成することを提案しますか？ 提案体制は素晴らしいと思いますが、現状は過小評価されています。

提案Bを採用すべきではないと言って提案Aを作成する必要はありません。 代わりに提案Bに反対票を投じてください。 提案Bの詳細については、その提案またはメーリングリストを使用してください。

（この場合の提案Bはロックされていることを理解しています。この提案には、1日以内に77のコメントがあるという事実が理由を示しています。このレベルのディスカッションは、課題追跡システムよりもメーリングリストでうまく機能します。）

@ianlancetaylor

（私はメッセージに返信することが可能であることに同意します。それは厄介で不可能ではないと言いました。そして、このミニスレッドが他のコメントの猛吹雪で失われるという点で、スレッドについての私のポイントはまだ残っています。）

十分に公平です、それは理にかなっています。 メーリングリストは素晴らしいですが、この場合、個人的にはGitHubを介して投稿する方が簡単だと思います。 現在のエラー処理が素晴らしいこと以外は言うことはあまりありませんが、それが変わらないことを願っています。 絵文字/投票はこれに最適です。 100人の「投票」で十分なメーリングリストに「エラー処理をそのままにしておいてください」と100人が書くことはおそらく望ましくありません。

この問題はロックされているため、絵文字で「投票」することはできなくなりました。 そのため、この問題はそもそも作成されたと思います。

副次的な点ですが、関連する依存関係の管理はうまく処理されませんでした。 Depはうまく機能し、どこからともなくgo modが選択されました（見た目から）[1]。 これが提案制度ができた理由だと思います。 この場合の提案システムは、問題がロックされていて、メーリングリストに行くように言われた場合、コミュニティを過小評価する可能性があると感じています。

[1] https://twitter.com/_rsc/status/1022588240501661696

編集：Goチームとコミュニティは、ほとんどの場合、コミュニティのフィードバックを聞いて素晴らしい仕事をしています。 私はそれに入るすべての仕事に感謝します。 Go調査は良い例です。

@sanbornm

Depはうまくいきました

ここで反対する必要があります。 Goモジュールは、 https： //proxy.golang.orgによる永続的なキャッシュに関する、よく知られていない「gobindata」の問題を最終的に解決しました

その担当者は問題に気づかず、代わりにVCSを介して派手な「保証」をいじっていました。

@sirkonこれは少し外れたトピックですが、Depが行っていたようにベンダーのdepが行っている場合は、そのいずれも必要ありません。

現状では、1行に1つのtryステートメントのように、制約が追加されない限り、そのままにしておくほうがいいと思います。 その理由から、この例を考えているの提案-それは十分に無害と思われるinfo := try(try(os.Open(file)).Stat())が、それは通常どのような制御フローの範囲を超えてファイルハンドルをリークします。 io.Closer実装や、よりコンパクトなコードを追求するために人々が回避する可能性のあるその他のクリーンアップ関数を使用すると、ファイルリソースリークが増加すると思います。

fがライブではなくなり、すぐにGCの対象になり、ある時点でファイナライザーがfを確実に閉じるため、重要ではないと考える人もいるかもしれません。 これにより、関数ブロックにバインドされている、今日のdeferを使用するという以前の明確な（リンターでサポートされている）規則が変更されると思います。 機能ブロックが終了すると、リソースが解放されます。 ガベージコレクターに依存しても、リソースを使い果たしないという保証はありません（通常、開いているファイルハンドルの制限のデフォルトは1kから4kの間です）。これは、単純なファイルパスで簡単に超えられます。

要約すると、実装されたこの構文は、ctor / dtorがなく、リソースリークを防ぐためにコードブロックから遠く離れた低レベルのGC機構に依存しているため、Goのリソース管理に微妙なリスクをもたらすと思います。 無害と思われるものを潜在的なエラー状態（開いているファイルが多すぎる）に変える。

var n int
for _, name in try(os.Readdir(...)) {
   n += try(getSize(name))
}
func getSize(name string) (int, error) {
   return try(try(os.Open(name)).Stat()).Size
}

編集：
制約については、 a, b := try(get("a")), try(get("b"))で十分であるため、割り当ての右側でのみ有効である場合は、1行に1つと言うよりも適切だと思います。 ただし、それでもtry(os.Open(name)).Stat()を実行する機能は残ります。これは、try（）を無効にした場合に限りますが、割り当てのRHSにない場合にのみ、次のように機能しないものが残ります。全て。

@cstocktonすごい素晴らしい発見！

Rustには実際には同様のマクロ（私が正しく覚えていれば? ）があり、このtry意図したとおりに動作しますが、適切なraiiがあるため、その言語では問題はなく、巨大です私たちの場合の穴

@sanbornmええ、あなたのリポジトリにインターネットの半分を保持することは確かに素晴らしいアイデアのように見えます。

try時間と労力を節約できる場所の数を数えるユーティリティについて誰かが言及し

| プロジェクト| LOC * | 候補者を試す|
| ---------- | ------ | ---------------- |
| cal1 | 2047 | 3 |
| pump1 | 1030 | 0 |
| docs1 | 4576 | 8 |
| hugoutil | 604 | 1 |
| 他のすべて| 8452 | 23 |

• clocユーティリティに従って、コメントを除いてコードのみを実行します。

「その他すべて」の内容には、Goを学んでいたときに書いた簡単なハックとコードが含まれていることに注意してください。

私の全体的な結論は、少なくとも私にとっては、 try提案は、私のエラー処理を価値のある程度まで合理化するのに役立たないということです。

私が行くのが大好きな最大の理由は、その仕様がコーダーを他の言語で利用可能な構文の小さなサブセットに制限していることです。 これは非常に小さな機能セットであるため、機能セット全体を簡単に学ぶことができます。 将来の開発者はおそらく私のコードを見て、私が何をしたかを知ることができます。 言語に新しいものが追加されるたびに、将来の開発者がそのことを知る可能性が低くなります。 滑りやすい坂の極端な部分は、C ++やscalaのように、複雑さのために理解しにくい言語です。
go1に構文が追加されないようにしたいのですが。代わりにgo2に入れてください。

@miekgこのリンクhttps://github.com/golang/go/issues/32825#issuecomment-506882164を提案に追加してください。 この例では、この最近のtryキーワードのアイデア全体が完全に失格になっています。

そのままにしておくことに完全に同意します。 少し冗長すぎますが、従うのはかなり簡単です。

減らすことができれば

if err := foo.x(a, b); err != nil {
  return err
}

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

if err := foo.z(c); err != nil {
  return err
}

のようなものに

if err := check foo.x(a, b), foo.y(), foo.z(c); err != nil {
  return err
}

イディオムをあまり変えなくてもいいかもしれません。

「たぶん」タイプについて話していた場合、最初にバリアントタイプが必要です。

if err != nilが機能するようにしましょう。それは明らかで、それほど冗長ではなく、コードの流れの中で理にかなっています。 このコンストラクトを使用してコードを読むと、それが何をするのかがわかります。
それを維持しましょう、 try追加しないでください

コードを読むときは、エラー処理の有無にかかわらず、ジョブを実行している行を明確に読み取れるようにします。

同じレベルの3文字の「err」は私には受け入れられます。 重要なコードは第2レベルにあるため（lispを覚えていますか？）、重要なコードをラップする「check」関数は必要ありません。また、重要なコードがインデントされるため、前に「try」行を使用したくありません。そして2行目に。

res、err：= begin_job（）
if err！= nil {
handle_error（）
}

err = continue_job（res）
if err！= nil {
handle_error（）
}

このコードを使用すると、ブロックの最初の行を読み取ることで、エラー以外のケースのフローを読み取ることができます（すばやく読む必要があるときにドキュメントのタイトルを読むため）

try時間と労力を節約できる場所の数を数えるユーティリティについて誰かが言及し

プロジェクトLOC *候補者を試す
cal1 2047 3
pump1 1030 0
docs1 4576 8
hugoutil 604 1
他のすべて845223

• clocユーティリティに従って、コメントを除いてコードのみを実行します。

大規模なプログラムではtryがもっと必要だと思います。 メモリから描画するだけで、LOCサイズが約15〜20k以上のプログラムでは、より多くのプログラムが必要になると思います。これは、クローズドシステムで適切に指定および処理されるため、エラーを渡す必要があるレイヤーを取得し始める可能性があるためです。送信側と受信側の両方。 それはそれがどの種類のプログラムであるかに大きく依存します。 私はおそらく小さなプログラムでもあまり試してみないでしょう

大規模なプログラムでは、試してみる必要があると思います。

いい視点ね。 heptio / contour、28.7k行のソーステキストでtryhardを試しましたが、tryhardは12個の置換を見つけました。

大規模なプログラムでは、試してみる必要があると思います。

いい視点ね。 heptio / contour、28.7k行のソーステキストでtryhardを試しましたが、tryhardは12個の置換を見つけました。

わお！ 12対28.7K行、これには本当に専用のキーワードが必要です！

まあ、私はこれに関するあなたのPOVにもっと興味があります：

stat := try(try(os.Open(fileName)).Stat())

プログラムがもう少しモノリシックで、多くのサービス間のサービス統合の一部ではない場合は、より一般的だと思います。 そのリポジトリ（ heptio/contour ）のgithubでfmt.errorfまたはerrorsを検索すると、結果が非​​常に少ないため、簡単な概要を取得するのは困難です。大規模なプログラムであっても、プログラムごとに大きく異なる可能性があると述べました。

多くの外部ライブラリを使用しない単一のプログラムがあるとします。 次に、特定のAuthorizationErrorを設定できます（返されるすべてのエラーは、すでに処理およびラップされているioエラーで十分に具体的であることがわかります）。これには、ユーザーメタデータが既に含まれており、実際に必要なものに大きな変更を加えることなく、いくつかのレイヤーを変更せずに伝播できます。リクエストレイヤーまでそれらを処理します。

プログラムがもう少しモノリシックで、多くのサービス間のサービス統合の一部ではない場合は、より一般的だと思います。 そのリポジトリのgithubでfmt.errorfまたはerrorsを検索すると、結果が非​​常に少ないため、簡単な概要を取得するのは困難です。しかし、私が言ったように、プログラムによって大きく異なる可能性があります。大規模なプログラムであっても、プログラムする。

多くの外部ライブラリを使用しない単一のプログラムがあるとします。 次に、ユーザーメタデータがすでに含まれている特定のAuthorizationErrorを作成し、リクエストレイヤーまで実際に処理する必要のあるものに大きな変更を加えることなく、いくつかのレイヤーを変更せずに伝播できます。

わからない。 注釈は、エラーが発生した方法を簡単に見つけるためのものです。 同様にos.NotExistが、これはエラーパスに関する良いヒントにはなりません。

@thomasfは、

529628ソース行、tryhardは1763（0.3％）の置換を検出しました。

ええ、確かに。 あなたは両方に関わってきたので、プログラムを書くためのさまざまな方法の良い例ではないかもしれません。 tryhardプログラムatmを試す時間すらなく、さまざまなソースで適切に実行する時間がありません（github経由で収集された場合、クローズドソースコードが省略されるため、とにかく収集できない可能性があります）

529628ソース行、tryhardは1763（0.3％）の置換を検出しました。

誰か（要出典）が賢明に言ったように、 tryはエラーの処理を容易にしません。 それはそれらを扱わないことをより簡単にします。

コードを分析してtry置換をたくさん見つけた場合、コードはエラーを返す以外は何もしないということだけがわかります。 それはおそらく素晴らしいコードではありません。 人々が怠惰になり、エラーを心配しないようにする必要がありますか？ それを正確に回避するために、Goに例外がない理由の1つではありませんか？

私はその立場を取るつもりはありません。 しかし、私が見つけているのは、それを示唆する彼らの小さな裏付けとなる証拠です

NS。 tryが既存のgoコードベースに適用できる場所はたくさんあります
NS。 一般に、エラー処理はSLOCの重要な部分を構成します。これは、私自身の測定値とGoチームによって決定された数値に基づいています。参照

コードを分析してtry置換がたくさん見つかった場合、コードはエラーを返す以外は何もしないということだけを示しています。 それはおそらく素晴らしいコードではありません。 人々が怠惰になり、エラーを心配しないようにする必要がありますか？ それを正確に回避するために、Goに例外がない理由の1つではありませんか？

1. あなたは、良い習慣ではないことについて何も知らない理論的コードについて価値判断を下しています。
2. tryが現在よりも誤用されやすいかどうかはわかりません。goにはエラー処理を強制する機能がなく、すでにスキップするのは非常に簡単です。 私にとってはtryそれがエラーを処理する必要がない場合は読みやすいコードを作りについてです。

tryは多くの場所で必要とされないため、必要ないかもしれませんが、単に不機嫌になるのではなく、アイデアを楽しませてユースケースを考えてみましょう...

自分でどうやって使うのか、自分ではあまり考えられませんが、まだ存在していないので、もしあったら違うデザインにするかどうかはわかりません。 doは、tryを使用してこのような無名関数にいくつかのアクションをグループ化し、呼び出し元に返す前にエラーを処理します。 これにより、一部のコードがはるかに読みやすくなる可能性があります。

var v1, v3 string
if err := func() error {
    try(onething())
    v = try(twothing())
    try(otherthing())
    v3 = try(somethingg())
}(); err != nil {
  ... handle error...
}

この時点で、さまざまなパッケージのtryhardデータを保持し、それらを視覚化するWebサイトを作成することをお勧めします。 たぶん、golang / gddo（godoc.org）を少し変更するだけでうまくいくでしょう。

私はif err != nil放っておくほうが好きです。 ただし、エラー処理のために何かを追加する必要がある場合は、 throwsキーワードを追加する新しい提案があります。

32852

ここですでに説明した議論のいくつかを繰り返さずに、私はif err != nilをそのままにしておくという感情をエコーし​​ます。

私が提供できる視点は次のとおりです。何百人もの新参者（プログラミングと他の言語からのGoの両方）にGoを教えた人として、 if err != nilは彼らにとって決して問題ではありませんでした。 私のワークショップの経験豊富なプログラマーは、最初は珍しいことに気づきますが、すぐにGoでのエラー処理の明示的な性質を愛するようになります。

言語で対処できるより大きな懸念があり、この問題に対するコミュニティの明確な反応は、 if err != nilはそれらの1つではないと言っています。

Goは多くの理由で完璧です。 その中で最も重要なのは「iferr！= nil」です。 冗長に見えるかもしれませんが、コーディングを学ぶ人々にとっては、コードのデバッグとコードの修正が容易になります。

@davecheney

私はその立場を取るつもりはありません。 しかし、私が見つけているのは、それを示唆する彼らの小さな裏付けとなる証拠です

NS。 tryが既存のgoコードベースに適用できる場所はたくさんあります
NS。 一般に、エラー処理はSLOCの重要な部分を構成します。これは、私自身の測定値とGoチームによって決定された数値に基づいています。参照

現在の状況では、私たちが見つけた例は「まあ、それはおそらく良いコードではない」として却下されるのではないかと心配しています。

次に例を示します。

llorllale:~/go/src/github.com/hyperledger/fabric$ cloc --exclude-dir=vendor .
    2406 text files.
    2256 unique files.                                          
    3130 files ignored.

http://cloc.sourceforge.net v 1.60  T=6.69 s (272.8 files/s, 58350.9 lines/s)
--------------------------------------------------------------------------------
Language                      files          blank        comment           code
--------------------------------------------------------------------------------
Go                             1751          54365          34149         294005
YAML                             35            547           2171           2060
Bourne Shell                     26            354            325           1312
make                              3            135             96            418
CSS                               1             40             14            140
HTML                              3              7              5             63
Python                            1             50            103             57
Bourne Again Shell                1              1              6             50
Java                              3              7              4             26
XML                               2              1              4              2
--------------------------------------------------------------------------------
SUM:                           1826          55507          36877         298133
--------------------------------------------------------------------------------

llorllale:~/go/src/github.com/hyperledger/fabric$ tryhard -l . | grep -v vendor | less | wc -l
1417

公平を期すために、tryhardが見つけた場所の数に関するデータは、ラッピングエラーを必要とする規則によって混乱する可能性があります。 たとえば、あなたの会社の慣習が

if err != nil {
   return errors.Wrap(err) 
} 

...
if err != nil {
   return errgo.Notef(err, "error doing x") 
} 

それはtryhardによって報告されないでしょう。

私の会社ではそのような大会があります。 単純な検索と置換を実行してそれらをネイキッドエラーリターンに戻すと、次の結果が得られます。

Language                             files          blank        comment           code
---------------------------------------------------------------------------------------
Go                                    2488          40317          15901         297038

tryhardは2736の置換を報告していますが、残りのラッピングを手動で確認すると、約1850が過小評価されているように見えるため、コードベースの30万行で合計約4500 try使用量を見積もっています。

（個人的には、エラー処理の現在の明示性に賛成であり、気にしません。）

たとえば、あなたの会社の慣習が
[エラーをカスタムメッセージでラップする]
それはtryhardによって報告されないでしょう。

それがポイントです— tryプロポーザルはif err != nil return errネイキッドリターンを単純化するだけで、カスタムメッセージとコンテキストによるエラーのラッピングをサポートしていません。

if err != nilの唯一の反復性は、他の戻り値のゼロ値も指定する必要があるので修正できると思います。 言語を更新して、それを排除することができます。 例えば：

今日のGoで、このシグネチャを持つ関数がある場合：

func add(x, y string) (int, error)

関数のどこかに、次のように書く必要があります。

func add(x, y string) (int, error) {
    // ...
    if err != nil {
        return 0, err
    }

関数全体で同じゼロ値を繰り返すようにライターに強制します。

言語がエラー以外の戻り値のゼロ値を自動的に入力できれば、はるかに簡単になります（そして、エラーの冗長性と可読性にほとんどコストがかかりません）。

func add(x, y string) (int, error) {
    // ...
    if err != nil {
        return ..., err
    }
    // ...
}
func main() {
    add("8", "beep") // returns 0, error(`strconv.ParseInt: parsing "beep": invalid syntax`)
}

DBクエリや呼び出しと相互作用する多くのコードの経験から、関数全体でゼロ値を繰り返さなければならないことが、Goスタイルのエラー処理の唯一の欠点であると言えます。 そうでなければ、私はこの提案の感情に同意します： if err != nil放っておいてください！

注：はい、名前付きの戻り値はこれを_ソート_達成できます（https://play.golang.org/p/MLV8Y52HUBY）が、この手法を使用して自分のコードベースにいくつかの関数を実装した後、私はどれだけの足がかかるかを思い出しました-銃の名前付き戻り値は次のとおりです。 私はいつも名前付きの戻り値をシャドウイングすることになります。

たとえば、あなたの会社の慣習が
[エラーをカスタムメッセージでラップする]
それはtryhardによって報告されないでしょう。

それがポイントです— tryプロポーザルはif err != nil return errネイキッドリターンを単純化するだけで、カスタムメッセージとコンテキストによるエラーのラッピングをサポートしていません。

それは本当です、私は説明的な文字列を追加することを可能にするバリアントを考えていました。 エラーリターンの大部分（〜4000 / 4500）は、コンテキストなしのerrgo.Mask(err)であり、説明なしのtry()と同等であると考えていましたが、現在はerrgoはスタック情報を追加し、tryは（まだ）追加しないため、機能。

@ianlancetaylorここに提案があります。 @miekgは、私たちの言語のリーダーの1人として、if err != nilを置き換えることをもはや追求しないことを提案しています。 個人的には、他の提案のように扱うのではなく、 golang-nutsに移動して、この質問の重要性を主張しようとしているように感じます。 それはあなたの意図ではないかもしれませんが、それは私が感じる影響です。

私たちのエラー処理方法は独特であり、他の言語よりも大きな付加価値があると思います。 それは私が構築するシステムのエラーについての私の考え方を完全に変え、その結果、私はより強力なソフトウェアエンジニアになりました。 より多くのGo開発者を獲得するために、大声で少数派や部外者に詮索したくありません。 コードの簡潔さをトレードオフすることで究極的にはより良くなるので、エラーの処理方法を選択する方法はその1つであるため、特定の事柄については厳しい方針を取る必要があると思います。

これは、Google内のチームがコミュニティとの信頼と信頼を築く、または言語、エコシステム、またはそのユーザーにとって良くない現在の軌道を継続する機会です。

Goチームは、この提案をそのまま受け入れる一方で、より明確な付加価値を持つ他の無関係な言語の反復を引き続き追求するようお願いします。

トラッカーにはスレッドがない可能性がありますが、個人的には、この提案が公式の立場で応答され、静かに曖昧になる可能性のあるGoogleグループに追いやられないことを保証したいと思います。

このトピックはすでにGoogleグループでも議論されています。

＃32437の現在のバージョンは満足のいくものではありません。 try（）ビルトインは、訓練されていない目に多くの実行パスを隠します。 チェックとハンドルを使った元の提案は非常に理解しやすく、checkキーワードが際立っていました。

現在、組み込みのtry（）は関数のように見えます。これにより、制御フローを変更できるかどうかは明らかではありません。 panic（）もありますが、（私は信じていますが）常に独自のライン上にあり、目立つ名前があり、その使用はほとんどありません。 一方、try（）は、複雑な式の中に隠れることがあります。

@theckman Robertは、Go with RobとKenの最初のイテレーションを設計し、RobertとRussは早い段階でチームに参加しました。 彼らは最初からGoに取り組んできました。 提案が「元のGo作成者によって決定されたエラー処理の精神と矛盾する」かどうかを知ることは彼らに信頼できると思います。

今日のようにエラー処理を凍結するという提案の原則は嫌いです。 そのような提案は、このトピックに関する将来のすべての提案を禁止します。

代わりに、デザインの反復を受け入れるだけではどうでしょうか。 チェック/ハンドルの提案がありました。 しかし、いくつかの欠点が議論されました。 これが試用提案につながりました。 この提案のいくつかの欠点について、ここで説明します。 おそらくこれは、正しいアプローチが見つかるまで、別のより良い提案につながるでしょう。

私たちのエラー処理方法はユニークです

Rustでのエラー処理は、概念的にはGoで行うものと似ています（エラーは値であり、明示的な制御フローですが、代わりに合計型を使用する場合は複数の戻り値を使用します）。 Rustには、Goと同じ問題があり、詳細なエラー処理が行われました。 これにより、Rustは試してみました！ マクロ、そして最終的には？ オペレーター。 Rustコミュニティは、エラー処理に関してGoコミュニティよりもさらに厳格だと思います（エラー処理のRFCと議論は啓発的です）。 彼らは、悪いエラー処理の滑りやすい坂を使わずに、エラー処理の冗長性を減らす方法を見つけました。 私たちもできると確信しています。

言語、エコシステム、またはそのユーザーにとって良くない現在の軌道

あなたは何について話していますか？ Goは常に改善されています。 このような素晴らしい言語、ツール、ドキュメントに無料でアクセスできるのは素晴らしいことです（言論の自由のように）。

@theckman Robertは、Go with RobとKenの最初のイテレーションを設計し、RobertとRussは早い段階でチームに参加しました。 彼らは最初からGoに取り組んできました。 提案が「元のGo作成者によって決定されたエラー処理の精神と矛盾する」かどうかを知ることは彼らに信頼できると思います。

今日のようにエラー処理を凍結するという提案の原則は嫌いです。 そのような提案は、このトピックに関する将来のすべての提案を禁止します。

代わりに、デザインの反復を受け入れるだけではどうでしょうか。 チェック/ハンドルの提案がありました。 しかし、いくつかの欠点が議論されました。 これが試用提案につながりました。 この提案のいくつかの欠点について、ここで説明します。 おそらくこれは、正しいアプローチが見つかるまで、別のより良い提案につながるでしょう。

私たちのエラー処理方法はユニークです

Rustでのエラー処理は、概念的にはGoで行うものと似ています（エラーは値であり、明示的な制御フローですが、代わりに合計型を使用する場合は複数の戻り値を使用します）。 Rustには、Goと同じ問題があり、詳細なエラー処理が行われました。 これにより、Rustは試してみました！ マクロ、そして最終的には？ オペレーター。 Rustコミュニティは、エラー処理に関してGoコミュニティよりもさらに厳格だと思います（エラー処理のRFCと議論は啓発的です）。 彼らは、悪いエラー処理の滑りやすい坂を使わずに、エラー処理の冗長性を減らす方法を見つけました。 私たちもできると確信しています。

言語、エコシステム、またはそのユーザーにとって良くない現在の軌道

あなたは何について話していますか？ Goは常に改善されています。 このような素晴らしい言語、ツール、ドキュメントに無料でアクセスできるのは素晴らしいことです（言論の自由のように）。

Rustの開発の歴史は、その背後にいる人物が彼らが何をしているのか見当がつかなかったことを示しています。 彼らは基本的にHaskellからエラー処理の原則をコピーしましたが、これらは命令型（現実世界？）のプログラミングには適していません。 それらの?マクロは、最初に失敗したエラー処理システムの単なる回避策です。

@ianlancetaylorここに提案があります。 @miekgは、私たちの言語のリーダーの1人として、if err != nilを置き換えることをもはや追求しないことを提案しています。 個人的には、他の提案のように扱うのではなく、 golang-nutsに移動して、この質問の重要性を主張しようとしているように感じます。 それはあなたの意図ではないかもしれませんが、それは私が感じる影響です。

私たちのエラー処理方法は独特であり、他の言語よりも大きな付加価値があると思います。 それは私が構築するシステムのエラーについての私の考え方を完全に変え、その結果、私はより強力なソフトウェアエンジニアになりました。 より多くのGo開発者を獲得するために、大声で少数派や部外者に詮索したくありません。 コードの簡潔さをトレードオフすることで究極的にはより良くなるので、エラーの処理方法を選択する方法はその1つであるため、特定の事柄については厳しい方針を取る必要があると思います。

これは、Google内のチームがコミュニティとの信頼と信頼を築く、または言語、エコシステム、またはそのユーザーにとって良くない現在の軌道を継続する機会です。

Goチームは、この提案をそのまま受け入れる一方で、より明確な付加価値を持つ他の無関係な言語の反復を引き続き追求するようお願いします。

彼らは60年代からの現在の型システムでは深刻なことは何もできません。 彼らは最終的にGo2.0で80年代のアイデアを借りる必要があります

あなたは何について話していますか？ Goは常に改善されています。 このような素晴らしい言語、ツール、ドキュメントに無料でアクセスできるのは素晴らしいことです（言論の自由のように）。

@ngrillyその最後の部分は、おそらくより大きな議論のためのものです。 この提案を狂わせることなく、そのコメントにいくらかの閉鎖を加えることで、ユーザーとコミュニティ/エコシステムのリーダーシップとの間の不整合の感情が高まっています。

残りの議論では、構文に認知的オーバーヘッドを追加することは勝利ではないと思います。 彼らが彼らのために働く何かを見つけてくれてうれしいです、私たちは彼らではありません。

インラインifステートメントの提案を開きました： https ：

参照： https ：

誰もが自分の好きな新しいgolang2.0機能について提案を提出すると、 https：//github.com/golang/go （およびその他の機能）のフォークのブランチも提供され、この世界はどれほど素晴らしいものになるでしょう。その提案を実装するリポジトリが必要です）。

同意しませんか？

@ av86743この提案の範囲を超えているようです。 その行動方針を提案する提案を提出してください。

誰かが提案書自体の何かに基づいてそれを断る前に多くの無駄な努力のリスクのような、私はそれにいくつかの挑戦を見ます。 それからあなたはその間ずっとレビューさえされないフォークに費やしました。

この構文はどうですか：

# call error handler
try callFunction(), errorHandler()

# error handler with anonymous function
variable := try callSomething(), func(err *Error) { # error handling }

@theckmanこの議論を他の場所に移すという私の提案が、それが重要でないと思われる場合は、お詫び申し上げます。 私は私の要求で私の理由を説明しました、そして私は彼らがまだ立っていると信じています。 Goチームは、提案だけでなくメーリングリストのディスカッションも検討します。

「オリジナルのGo作者」とおっしゃっていますが、「try」の提案は、3人のオリジナルのGo作者の1人である

私はこの提案に強く同意します。変更する必要があるのは、go fmtだけで、1行のifステートメントを許可するようにgofmtを作成することだけだと思います。

私は本当に一行欲しい

if err != nil { return wrappedErr{err} }

3行の代わりに

if err != nil {
    return wrappedErr{err}
}

@ av86743この提案の範囲を超えているようです。 その行動方針を提案する提案を提出してください。

@theckmanあなたは私に何をすべきかを言っています、そしてこれは丁寧であるだけでなく、外見的に失礼です。 あなたは自分の好きなように自分の位置を決めることができますが、私自身も、おそらくここにいる他の誰も、あなたがそう言うときにジャンプするあなたの「フェッチに行く」猿ではありません。

誰かが提案書自体の何かに基づいてそれを断る前に多くの無駄な努力のリスクのような、私はそれにいくつかの挑戦を見ます。 それからあなたはその間ずっとレビューさえされないフォークに費やしました。

それは[..._簡潔にするために省略された完全に適切な言語での説明_...]の「無駄な努力」にすぎません。

ただし、コーダーにとっては、それは些細なことですが、便利な演習であると同時に、Goコミュニティへのサービスでもあります。

@ av86743あなたが提案したことは興味深いアイデアだと思います。そして、関係のない問題のコメントとしてそれが失われることを望んでいませんでした。 公的な検討の立場でそれを追求することに興味がない場合は、別の問題を提起することを提唱して申し訳ありません。

この特定の提案は@griesemerからのものGoでのラップされていないエラーリターンの冗長性について、彼が10年間内なる怒りに沸騰しているとは信じられません。 ただし、彼は優れたエンジニアであり、エンジニアは（認識された）問題の解決策を考え出します。 それらを止めるのは非常に難しいです。 私たちは問題を解決するのが好きです。 問題を嗅ぐだけで、あらゆる種類のアイデアを思いつくことができます。 その思考プロセスがかなり進んだら、私たちの誰もが私たちの推定上の解決策を感情的に手放し、_おそらくそれは結局のところ実際には問題ではない_と考えるのは難しいです。 結局のところ、私たちは知的に言えば赤ちゃんを産んだので、それを捨てるのは簡単ではありません。

私の個人的な疑いは、これに関するGoチームの推論プロセスが次のようになったことです。

1. Goは非常に人気があり、広く使用されているため、当然のことながら、何千人もの人々がGoについてコメント、提案、苦情を持っています。
2. あなたはとても長い間しか石垣を作ることができません。 Goチームは、コミュニティからのすべての騒音について_何か_をするという大きなプレッシャーにさらされていると感じています。
3. これは何かです。

tryがrecover（）のようなエラーを見つけた場合にキャッチするために、deferにcatch（）関数を追加するのはどうですか。
例：

func doSomthing()(err error){
    //return error
}

func main(){
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

    try doSomthing()
}

多くの機能で

func Foo() (err error) {
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

   try{
    file1 := open("file1")
    defer file1.Close()
    file2 := open("file2")
    defer file2.Close()
   }
   //without try
    file3,err := open("file3")
    defer file3.Close()
 }

tryがrecover（）のようなエラーを見つけた場合にキャッチするために、deferにcatch（）関数を追加するのはどうですか。
例：

func doSomthing()(err error){
    //return error
}

func main(){
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

    try doSomthing()
}

多くの機能で

func Foo() (err error) {
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

   try{
  file1 := open("file1")
  defer file1.Close()
  file2 := open("file2")
  defer file2.Close()
   }
   //without try
    file3,err := open("file3")
    defer file3.Close()
 }

これは、各エラーを個別の方法で処理するのにどのように役立ちますか？

いくつかの説明：

1. try提案は、このスレッドで主張していることとは反対に、新しい構文も新しいキーワードも導入していません。 これは、新しい機能を追加するために実行できる可能性のある最小限の変更について、新しい組み込みを導入するだけです。 それが重要なので、これを議論するときは正確に言ってください。 新しい構文と新しいキーワードの追加と、組み込みの追加には大きな違いがあります。 前者は大きな変更であり、後者は比較的小さな追加です。 try提案が示唆しているのは、比較的マイナーな追加です。

2. @ianlancetaylorは、この議論が他の場所（golang-nuts）で行われる方がよいことに同意します。 ここに提案はありません。

3. 確かに、 @ bitfield 、 「 Goでのラップされていないエラーリターンの冗長性についての内なる怒り」はありません。ありがとうございます:-)しかし、エラーチェックはおそらく必要以上に冗長だと思います。 そして、この同じ感情がコミュニティによって繰り返し提起されてきたという事実は、私たち（Goチーム）がこの信念を持っているだけではないことを明確に示しています。 私は「何か」をするために多くのプレッシャーがあるとまでは言いません-私たちはこれに長い間取り組んできました、そして私たちは「正しい」アプローチを待つことに非常に満足しています。

try提案は、エラーチェックの問題に対処するために私たちが見つけた（コミュニティの貢献からの多大な助けを借りた）最小限の解決策に関するものです。 try提案は、すべてのエラーテストで特定の方法でエラーを処理する必要がある場合、「まったく役に立たない」という事実について非常に明確です。 tryは、関数内のすべてのエラーが同じ方法でテストおよび処理される場合（そして、 deferを使用することをお勧めします）、または単に返される場合にのみ役立ちます。 ここでより明確にするのは難しいですが、提案が述べていることを繰り返しましょう： tryはすべてのエラーシナリオで役立つわけではありません。 それはかなりの数の場合に役立ちます。 それ以外の場合は、 ifステートメントを使用します。

@griesemer tryはエラーが発生しやすいため、GoにはRAIIがないため、多くの場合、関数をそのままにしておくことはできません。

@ sirkon 、RAIIがこの議論にどのように関連しているかわかりません。 tryの既存のパターンを置き換えるif ..., err := f(); err != nil { return ..., err }して... := try(f()) 。 tryを使用してリソースを解放するバグがあった場合、それは確かに事前に存在していました。 tryの導入は、リソース解放のバグを強化も防止もしません。

@ sirkon 、RAIIがこの議論にどのように関連しているかわかりません。 tryの既存のパターンを置き換えるif ..., err := f(); err != nil { return ..., err }して... := try(f()) 。 tryを使用してリソースを解放するバグがあった場合、それは確かに事前に存在していました。 tryの導入は、リソース解放のバグを強化も防止もしません。

スレッドを読んでください、例がありました：

info := try(try(os.Open(fileName)).Stat())

@sirkon私はその例を数回見ました。 おもしろいことに同意します。 しかし、もう少し考えてみましょう。 提案されているtryビルトインは、基本的にGoコードにある特定の種類の定型文の構文糖衣です。 したがって、その例を元のコードに変換できます。

    f, err := os.Open(fileName)
    if err != nil {
        return err
    }
    info, err := f.Stat()
    if err != nil {
        return err
    }

そのコードにも同じバグがあります。 私は確かにそのようなコードを見てきました。 try組み込まれているため、バグが書きやすくなったり、見づらくなったりすることは私にはわかりません。

[ @ianlancetaylorが私を殴ったようです。]

@sirkonこのバグは、 tryあろうとなかろうと、すでに可能です-Goは、悪いコードを書くことを妨げません。 または、これを好転させて、 tryが許可されるべきではない理由として悪いコードを使用することは、説得力のある議論ではありません。 代わりに、 go vetは問題のあるケースにフラグを立てる必要があります。

deferは、関数が戻ったときにクリーンアップするGoイディオムであり、これはうまく機能します。 もちろん、ここでの正しいアプローチは次のとおりです。

f := try(os.Open(filename))
defer f.Close()
info := try(f.Stat())

これを以下と比較してください：

f, err := os.Open(filename)
if err != nil {
   return ..., err
}
defer f.Close()
info, err := f.Stat()
if err != nil {
   return ..., err
}

tryすると、ソースは主な関心事であるファイルのファイル情報の取得に集中します。 従来のアプローチを使用すると、ほとんどのソースコードは起こりうるエラーを懸念しています。 そしてそれはすべて同じです。 エラーを装飾したい場合でも、 tryアプローチは美しく機能します。

defer errd.Wrap(&err, "failed to do X for %s", filename)
f := try(os.Open(filename))
defer f.Close()
info := try(f.Stat())

errdパッケージのようなものを使用します（問題＃32676を参照）。

@griesemer
私の将来の自己実行コードレビューは、制御フローメカニズムがそれ自身のライン上にあるべきであるとまだ叫び続けています。 このアプローチは、現在の提案内で有効（強制なし）ですか？ 読みやすさに加えて、より詳細なエラー処理ロジックへのリファクタリングが容易になります。

defer errd.Wrap(&err, "failed to do X for %s", filename)
f, err:= os.Open(filename)
try(err) // check is so much a better term
defer f.Close()
info, err := f.Stat()
try(err)

また、このhandleへのアプローチはここでは見栄えがしますが、複数の延期が混乱することはありませんか？ それとも、関数スコープの同期がありますか？ もしそうなら、匿名の機能には独自のスコープが付与されますか？ そしてシャドウイング... eesh-誰が最初に、何が2番目に？

これはすべて、Goコードを書くための2つの「モード」があるように感じます。 そうではないと言ってください。

@griesemer確かに、バグは今日も発生する可能性がありますが、現在のtryの実装により、将来さらに蔓延するようになると強く感じています。 私ができる（）。think.Of（Has）Chaining（）。Of（Methods）のほぼすべての人気のある言語から来た誰かが、良くも悪くも彼らに根付いています。 これらの言語はすべて、パターンを自然で安全にする独自のイディオムを提供します。 型システムがすべての値に付随する障害条件を割り当てるように強制するため、Goですぐに障害にぶつかります。これを回避するための合理的なパターンはありません（または、試行提案が存在しません）。

この提案が受け入れられれば、彼らはif errボイラープレートを回避する方法になり、慣れ親しんだ方法でコードを書くことができるようになります。 tryが作成される前に書かれたstackoverflowの回答、ブログ投稿などに10年近くのGoコードが含まれることを除いて。 彼らはすぐにerrとifステートメントをtryで削除することを学びます。 彼らは、tryプロポーザルのStat()ように、必要なフィールドにアクセスできるようになるまで、 tryラップされたコードを貼り付けることができるファイルサイズを望んでいます。 それは彼らが慣れているパターンなので、Goを書いているときにそれを適用するのは当然です。 最もターゲットを絞ったGoOSはすべてをファイルとして扱うため、より多くのリソースリークが発生すると想定するのが妥当です。

それは、私が「今日すでにこれを行うことができる」という声明に強く反対する理由に私をもたらします-あなたは単にできないからです。 確かに-ファイルハンドルをリークする可能性があります。 しかし、Goはプログラマーに、スコープ内に識別子を持たせてファイルをリークすることをスキップする機会を与えません。 スキップされた各識別子fは、ファイルハンドルがリークされています。 この機能を使用するには、Goエコシステムの特定の著名なイディオムが壊れている必要があります。 したがって、今日設計された機能を導入すると、Goでリソースがリークするリスクが明らかに高まります。

とはいえ、 https： //github.com/golang/go/issues/32825#issuecomment -506882164で述べたように、いくつかの小さな調整が行われた場合、実際にはtryをサポートしますが、変更は言語への追加を歓迎しました。 試行に必要なのは、割り当てのRHSでのみ有効にし、戻り値をアドレス指定できないようにすることだけだと思います。 tryの使用法の「良い」例（1行に1回の試行である傾向があります）を、tryを使用する「唯一の」方法にします。

info := try(try(os.Open(filename)).Stat()) // compiler error
f := try(os.Open(filename)) // valid
// we were forced to assign f, so we still have an identifier to Close (serve linters and users alike)
defer f.Close()
info := try(f.Stat())
a, b := try(strconv.Atoi("1")), try(strconv.Atoi("2")) // also valid 
a, b := try(strconv.Atoi("1"), strconv.Atoi("2")) // maybe?
a, b := try strconv.Atoi("1"), strconv.Atoi("2")

これは言語に自然に適合し、 tryの現在のすべての利点を（利点と見なす場合はネストすることを除いて）欠点なしで維持すると思います。 tryのネストは、だれにも有利になるとは思いません。節約はほとんどありませんが、悪用の可能性は無限にあります。 今日は特に悪を感じていないので、これが私にできる最善のことです。

total := try(try(os.Open(filename)).Stat()).Size() + try(strconv.Atoi(try(ioutil.ReadAll(os.Stdin))))

しかし、あなたが私たちに任せれば、_we_は最悪のことを考えるでしょう。

@daved try(err)を2行目に配置することは、既存のtryプロポーザルで完全にサポートされています。 tryは、最後の値がerrorと入力します。これは、 try(err)と書くと自然に満たされます。

deferに関するあなたの懸念に従うかどうかはわかりません。異なるハンドラーが必要な場合、 deferは正しい選択ではない可能性があります。 代わりに、従来のifが必要になる場合があります（提案に明記されています）。

@cstocktonネストされたtryは非常に問題になる可能性があることに同意します。 しかし、 tryがあれば、ほとんどのコードはあなたが与えた（有効な）ます。 専門家は、真空でコーディングするのではなく、スタイルガイド、コードレビュー、およびグッドプラクティスに従う傾向があります。 ですから、私はここではそれほど心配していません（悪いコードや間違ったコードを書くことが可能であれば、誰かがそれをすることをよく知っています-そうです）。

スタイルの問題として、私たちはあなたが好むような制限を言語に課していません-私たちはそのためにgo vetを使用しました。 結局、書かれたソフトウェアの場合、効果は同じです。 しかし、それを言語で持たないことによって、私たちは自分自身を縛り付けていません。 これらの制限を適切に設定するのは難しいため、仕様が不必要に複雑になります。 go vetを調整する方がはるかに簡単で、言語を調整するよりも多くのことを学ぶので、よりスマートになります。

@griesemer説明してくれてありがとう。 コード例では、最初の行がvar err error場合、折り返しは両方のチェック済みエラーに影響を与える可能性がありますか？ シャドウイングが将来対処される可能性のある懸念事項であるという話を見てきました。 これにどのように関連する/可能性がありますか？

tryがrecover（）のようなエラーを見つけた場合にキャッチするために、deferにcatch（）関数を追加するのはどうですか。
例：

func doSomthing()(err error){
    //return error
}

func main(){
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

    try doSomthing()
}

多くの機能で

func Foo() (err error) {
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

   try{
    file1 := open("file1")
    defer file1.Close()
    file2 := open("file2")
    defer file2.Close()
   }
   //without try
    file3,err := open("file3")
    defer file3.Close()
 }

これは、各エラーを個別の方法で処理するのにどのように役立ちますか？

他のユーザーがコミットしたように

func Foo() (err error) {
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

    file1 :=try open("file1")
    defer file1.Close()
    file2 :=try open("file2")
    defer file2.Close()

        //without try
       file3,err := open("file3")
       defer file3.Close()
 }

@davedこれらの例では、 errが結果errorの名前であると想定されていました。 tryは、名前（または名前がない場合）に関係なく、常にその結果エラー変数を設定します。 errというローカル変数がある場合、それは別の変数です。 結果エラーを参照する場合は、別の名前を付ける必要があります。 これが無効である場合はすでにあることに注意してください。

func f(...) (..., err error) {
   var err error // << err already declared
   ...

一方、あなたが書く場合：

func f(...) (..., err error) {
   a, b, ... err := g() // redeclaration of err
   ...

割り当てのerrは、結果パラメータリストで指定されたものと同じです。 ここでは、非常に長い間すでにそうであったことと何ら変わりはありません。

PS： try議論のためにこの問題をハイジャックするのをやめて、元の提案に戻る必要があります。ロックが解除され、明日（7月1日）に再び議論できるようになります。

@godcong catch()関数（または同様の関数）では、エラーを取得することはできますが、設定することはできません（通常、エラーハンドラーとして動作する遅延関数で、囲んでいる関数のエラーを設定する必要があります）。 。 catch()が、囲んでいる関数のエラー戻り値のアドレスである*errorを返すようにすることで、機能させることができます。 しかし、言語に新しいメカニズムを追加する代わりに、エラー結果名を使用しないのはなぜですか？ これが説明されているtry提案も参照してください。

また、上記のPSを参照してください。

@griesemer

ここでより明確にするのは難しいですが、提案が述べていることを繰り返しましょう。試してみると、すべてのエラーシナリオで役立つわけではありません。 それはかなりの数の場合に役立ちます。 それ以外の場合は、ifステートメントを使用します。

これはまさにtry()提案の致命的な欠陥だと思います。以前はエラーチェックを行う唯一の方法がありましたが、今では2つあり、コードベース全体に混在しています。 また、少なくとも私が取り組んでいるコードベースでは、 if err != nil 20％未満をtry()に置き換えることができます。これは重要ではありませんが、エラー処理スタイルに分割します。

個人的には、代わりにすべてのif err != nilケースの95％を置き換えるのに十分強力なエラー処理構造を好むでしょう。 それは多くの人が好きだったと思います。

@griesemerあなたが参照しているスタイルガイド、グッドプラクティス、例、ドキュメントなどはすべて時代遅れであるため、人々が学び、ツールが

ここで角度を切り替えます。概説した潜在的な副作用に対して十分に強力なtryステートメントをネストするためのユースケースは何ですか？ 今日のGoコードは、チェーン可能でネスト可能で、試行分離された括弧パーティをどこにでも乱暴に表示できるようにすることで、どのように利益を得るのでしょうか。 私の推測では、そうではなく、ネストを試すように求められた人はいないと思います。関数として実装されているため、提案に付属しています。 言語仕様がより複雑になるため、ネストの削除やアドレス指定可能などの制約を追加して、ネストの乱用や微妙なエラーを制限する必要はありません。 ここでのテーマは、言語の複雑さの導入を防ぐためですか、それともエラーを処理するためのより良い方法を追加するためですか？

ここでの目標が言語仕様をより複雑にしないことである場合、選択は明確です。ジェネリックリターンとパラメーターを使用して新しい関数を追加しないでください。任意にネスト可能で、制御フローを提供し、指定された値のアリティを変更します（しかし、それらが特定の組み込みインターフェースを満たしている場合に限ります）、おそらく私が忘れている以上のもの、たとえば前例のない複雑さを持つ関数。 エラー処理を改善することが目標である場合、エラーを生成する新しい方法を導入せずにそれを行う必要があると思います。

@sirkon私はその例を数回見ました。 おもしろいことに同意します。 しかし、もう少し考えてみましょう。 提案されているtryビルトインは、基本的にGoコードにある特定の種類の定型文の構文糖衣です。 したがって、その例を元のコードに変換できます。

    f, err := os.Open(fileName)
    if err != nil {
        return err
    }
    info, err := f.Stat()
    if err != nil {
        return err
    }

そのコードにも同じバグがあります。 私は確かにそのようなコードを見てきました。 try組み込まれているため、バグが書きやすくなったり、見づらくなったりすることは私にはわかりません。

従来のフローが「遅い」と、ファイルを閉じる必要があることに気付く余地が増えることは明らかです。このtryは、人々が長い道のりよりもショートカットを好む傾向があるため、この種のリークを引き起こします。

@godcong catch()関数（または同様の関数）では、エラーを取得することはできますが、設定することはできません（通常、エラーハンドラーとして動作する遅延関数で、囲んでいる関数のエラーを設定する必要があります）。 。 catch()が、囲んでいる関数のエラー戻り値のアドレスである*errorを返すようにすることで、機能させることができます。 しかし、言語に新しいメカニズムを追加する代わりに、エラー結果名を使用しないのはなぜですか？ これが説明されているtry提案も参照してください。

また、上記のPSを参照してください。

Goの型システムは60年代に立ち往生していたため、当然、エッジケースをうまく処理できませんでした。 80年代のアイデアを借りるのに十分な先見の明がある場合は、エラーが発生しやすい微妙なフローを制御する方法があります。 あなたは今、中世の村にガラスと金属の建物を建設しようとしています。これらの中世の村には電気と水道のパイプがないので、あなたもそれを持っていないのは悪いことです。

golang/go自体で、新しく改善されたエラー機能がどの程度採用されるかを確認するのは興味深いことです。 あったとしても。

go2 fmtにプレーンなgo1.xを出力するオプションがあるかどうかを確認することも興味深いでしょう。

私自身の経験から、返されたエラーにコンテキストを追加して以来、次のようになっています。

import "github.com/pkg/errors"
func caller(arg string) error {
  val, err := callee(arg)
  if err != nil {
    return errors.Warpf(err, "failed to do something with %s", arg)
  }

  err = anotherCallee(val)
  if err != nil {
    return errors.Warpf(err, "failed to do something with %s", val)
  }

  return nil
}

サポートチームは、本番環境で発生する問題について私の意見を必要とすることはめったにありません。

私見ですが、エラー処理の改善は定型コードを減らすことではなく、エラーにコンテキストを追加するためのより便利な方法を提供すると思います。 私はまだtry（）を使用するための良い賢明な方法を見つけることができません。

たぶん、延期してコンテキストを追加します。

func caller(arg string) (err error) {
  defer func() {
    switch t := err.(type) {
      case CalleeErr:
        err = errors.Wrapf(err, "failed to do something with %s", arg)
      case AnotherCalleeErr:
        err = errors.Wrapf(err, "failed to do something with %s", val)
    }
  }()

  val := try(callee(arg))
  try(anotherCallee(val)
  return nil
}

タイピングの多くを節約するようには見えませんが、読みやすさとパフォーマンスを犠牲にしています。

次のようにtry（）を使用することになります。

func caller(arg string) error {
    val, err := callee(arg)
    try(errors.Warpf(err, "failed to do something with %s", arg))

    err = anotherCallee(val)
    try(errors.Warpf(err, "failed to do something with %s", val))

    return nil
  }

それは数行を減らします、それだけです。

私には、この問題のほとんどの解決策は、例外を使用する他の言語から分離されていると私が思っていた1つのことを壊しているように見えます。つまり、エラー処理メカニズムは制御フローとして使用されません。 これらのソリューションのほとんどは、何らかの形の制御フロー（チェック/処理、試行、キャッチ、期待）を追加します。その時点で、Goチームは例外を追加して1日と呼ぶ方がよいと思います。

ルビーに似たifとreturn特別なケースがあればいいのですが

return err if err != nil

PS言語デザインの経験が浅いのでご容赦ください。愚かなことを言った場合は、遠慮なく指摘して教えてください。

tryがrecover（）のようなエラーを見つけた場合にキャッチするために、deferにcatch（）関数を追加するのはどうですか。
例：

func doSomthing()(err error){
    //return error
}

func main(){
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

    try doSomthing()
}

多くの機能で

func Foo() (err error) {
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

   try{
  file1 := open("file1")
  defer file1.Close()
  file2 := open("file2")
  defer file2.Close()
   }
   //without try
    file3,err := open("file3")
    defer file3.Close()
 }

これは、各エラーを個別の方法で処理するのにどのように役立ちますか？

他のユーザーがコミットしたように

func Foo() (err error) {
    defer func(){
        if err:=catch();err!=nil{
            //found error
        }
    }()

  file1 :=try open("file1")
  defer file1.Close()
  file2 :=try open("file2")
  defer file2.Close()

        //without try
       file3,err := open("file3")
       defer file3.Close()
 }

あなたの例では、すべてのエラーを同じdefferで処理します。 カスタムメッセージとカスタム情報をエラーに追加したい場合はどうなりますか？

@ianlancetaylor 「推定リターン」をサポートするために「：=」演算子を拡張することを提案した人はいますか？基本的に、関数呼び出しなしでtryとまったく同じように動作します。 これは私が両側で見た多くの懸念を解決するでしょう：

• 機能の名前としてのtryは、これを関数として実装する限り、誰もが100％満足できるかどうかわからない名前を付けることに固執している限り、論争を呼んでいます。
• tryは前例のない数のことを行い、 append()ような入力を持ち、ユビキタスパターン（ if err != nil ）の代わりにpanic()ような制御フローに影響を与えます。 。
• try入れ子は、厳密な技術的議論から導き出された付加価値としてではなく、関数として実装するという決定の結果です。
• tryは、下位互換性を維持するための関数として実装されています

タイプのように単純にリターンを推測すると、物事は簡潔に見え、次のように「進む」ように感じます。

f, err := os.Open(filename)
if err != nil {
   return ..., err
}
defer f.Close()

info, err := f.Stat()
if err != nil {
   return ..., err
}

_この動作の正しいコンピュータサイエンスの説明をここに挿入します_、それまでは、短い変数宣言を介して推定されたリターンを解決します。

f := os.Open(filename)
defer f.Close()
info := f.Stat()

これは、以下よりもはるかに整然と見えます。

f := try(os.Open(filename))
defer f.Close()
info := try(f.Stat())

これにより、上記のすべての懸念が解決されますが、（私の意見では）もう少し「好きになる」と感じ、下位互換性を維持します。 説明も少し簡単に思えますが、 try()の関数呼び出しでの「暗黙の」戻りは、他のすべての言語でのtryのユビキタスな意味を考えると、本当に場違いに感じます。 実装について100％話すことはできませんが、ほぼ同じ努力で実行できる可能性があるようです。 AssignStmtは、組み込みと同じバックエンドコンパイルを通知するために、LHSのどの式がerr値を省略したかを指定するフィールドを追加できますか？

そのままのエラーチェックが好きですが、これが本当に解決しなければならない問題であるなら、新しいキーワードがおそらくより良い解決策だと思います。 どのソリューションにも制御フローの変更が含まれる可能性が高いため、それを可能な限り明確にすることが最善です。

この例では、 on errが設定されるたびにon条件が評価されます。

func example() (foo int, err error) {
    on err != nil {
        return foo, err
    }

    foo, err = calcThis()
    foo, err = calcThat(foo)

    return
}

これは、関数シグネチャで戻り値の名前を宣言しなくても機能します。

func example() (*int, error) {
    var err error

    on err != nil {
        return nil, err
    }

    foo, err = calcThis()
    foo, err = calcThat(&foo)

    return &foo, nil
}

これは複数回設定することもできます。 不自然な例を次に示します。

func example() (*int, error) {
    var err error

    on err != nil {
        return nil, err
    }

    foo, err = calcThis()

    on err != nil {
        return &foo, err
    }

    foo, err = calcThat(&foo)

    return
}

私の目には、これはGoのスタイルと読みやすさを維持しながら、各ステップで何が起こっているかを明確にします（パラダイムを理解すると）。これは、 errが設定されるたびにその条件を効果的に挿入するためです。

次のこともできます。

func example() (foo int, err error) {
    var message string

    on err != nil {
        return foo, errors.Wrap(err, message)
    }

    message = "failed to calc this"
    foo, err = calcThis()

    message = "failed to calc that"
    foo, err = calcThat(foo)

    return
}

最後に、これにはエラー処理を超えた適用性があります。 foo == 0の場合に戻りたいですか？ 別の不自然な例：

func example(i int) bool {
    on x == 0 {
        return false
    }

    x = calcSomeInt(i)
    return true
}

@cstockton

その方法でエラーを取り除くのは少し簡単すぎると抗議しようとしていましたが、次のようになりました。

• これは、 json.Unmarshalなどの_only_エラーを返す関数を備えた「落とし穴」です。 IMEの優れたコードレビューアは、これを非常に迅速に監視することを学びます。
• http.Handlerメソッドなど、エラー値を返さない関数では、構文エラーが発生します。
• エラーの処理方法を知っていれば、それについて考え、予測し、とにかくエラー値をキャプチャして、処理できるようにするでしょう。
• 発生したエラーを他の誰かの問題（呼び出し元の問題）にするために単に返すことを意図している場合、これはそれを達成しますが、コンテキストの注釈を明示的に追加する機会を逃すという小さな欠点があります。

だから、私が考えることができるすべての長所を比較検討し、明らかな欠点に気付かなかった後、私は...フェンスにいます。 私が考慮していない明らかでない欠点があるのではないかと思います。 しかし、私はこれがどこに向かっているのかが好きになり始めています。

私はこれが正しい対応方法であることを願っています、そして私はコミットしていません
深刻なフェイクパス。

7/1/19で、クリス・ストックトン[email protected]は書きました：

@ianlancetaylorサポートするために "：="演算子を拡張することを提案した人はいますか
「推定リターン」-基本的に、関数なしで試してみるのとまったく同じように動作します
電話。 [...]

この場合、私が興味をそそられるのは、私たちが何かを持っているということです
「commaOK」パラダイムに類似しており、「err」が省略されています。
譲受人は、明確に定義された状況下で許可されます。 価値
注意しますが、これを有効にするのにそれ自体では明らかに十分ではありません
命題。

ルシオ。

このバグはすでに発生している可能性があります。試してみてもどうかは関係ありません。Goを使用しても、不正なコードの記述を防ぐことはできません。 または、これを好転させて、試行が許可されるべきではない理由として悪いコードを使用することは、説得力のある議論ではありません。 代わりに、獣医は問題のあるケースにフラグを立てる必要があります。

@griesemer同意しません。 キーストロークを節約できますが、ポインタ演算は、不良で壊れたコードを簡単に記述できるという前提で、Goから除外されました。 これは、バグの検出をより困難にするのと同じタイプの機能だと思います。

data := try(ioutil.ReadAll(try(os.Open("foo.txt"))))

tryの典型的な例で

data := try(ioutil.ReadAll(try(http.Get("http://example.com/")).Body))

上記は正しいコードのように読み取られますが、応答本文が完全に読み取られ、その後ハッピーパスで閉じられるという要件は無視されます。 十分に長く見てみると、間違った例の嫌な優雅さは、将来これらのタイプのバグが発生することを明らかにするはずです。

この時点でコードを書く以上のことをレビューする人として、私はGoが不正確さをそれほど魅力的にする機能を追加しないことを望みます。

@ jesse-amano代入演算子を使用すると、明示的な代入ステートメントがないと、実際にはこのケースが発生しなくなります。以下は、今日とまったく同じように動作します。

json.Unmarshal(...)
(http.Handler)(h).ServeHTTP(w, r)

エラーを返すだけの値については、 return json.Unmarshal(...)ように返される資格があり、ifブロックの外側に値が存在する必要がないため、よりコンパクトな形式で表すこともできます。

if err := json.Unmarshal(...); err != nIl {
    return err
} 

この場合、私が興味をそそられるのは、「comma OK」パラダイムに類似したものがあることです。ここでは、明確に定義された状況では、「err」担当者を省略できます。 注目に値しますが、これを有効な提案にするのにそれ自体では明らかに十分ではありません。

動作は、親または任意のネストとチェーンなしで試すのと同じです。 大多数の人が言葉を壊さずに自然に感じるものを見つけるのは難しいと思います。 Goの作者はこのタイプの機能をGoに追加することをかなり決心しているようですので、現在の形式のtryはGoに適していないことを絶対に確信しているので、代替案を深く掘り下げています。 これは私が考えることができる最も近いものであり、BCを壊すことはありませんが、それでも十分な数の人々にとって正しいとは感じられないかもしれません。 いずれにせよ、トライの提案が拒否されるか、誰かがもっと多くの人が同意できる何かを思いつくことを願っています。

編集：@ jesse-amano申し訳ありませんがあなたのポイントを完全に逃しました！ エラーを返さない関数内にいると、典型的な割り当てカウントの不一致のコンパイルエラーが表示されると思いますか？ 試してみると、おそらくそのための新しいタイプのコンパイラエラーメッセージが表示されると思います。

@beoran https://github.com/golang/go/issues/32825#issuecomment -507126700について：エラー処理は状況ごとにすでに異なります：エラーを変更せずに返す場合もあれば、装飾されたエラーを返す場合もあります。エラーが発生した場合、エラーを（正しく）無視できる場合があります。 それらがすべて共有する唯一のこと（エラーを無視する場合を除く）は、 err != nilテストです（これはすでに複数の方法で実行できます）。 新しい言語機能がこれらすべてのケース（またはそれらの95％）をキャプチャするのは良いことですが、そのような構造は、すでに持っている他の制御構造と非直交的に干渉する可能性が非常に高くなります。 つまり、私たちが期待できる最善の方法は、これらのケースのいくつか（おそらく、20％、おそらく50％）を改善することです。

@cstockton https://github.com/golang/go/issues/32825#issuecomment -507136111について：ネストされたtryが残っている唯一の障害であり、 go vetでは不十分な場合、ネストされたtry禁止することを検討できると思います-それは十分に簡単です。 しかし、現時点では、私たちはまだFUD（恐怖、不確実性、疑い）の段階にあり、実際にtryを真剣に実験した人は誰もいないと思います。 私はそうしている人々が前向きに報告したことに注意します。

PS： try問題は、フィードバックのために再び開かれています。 あそこを続けましょう。

@cstocktonああ、絶対に。 明確にするために、私が目指していたのは、ほとんどの場合、エラー値をキャプチャせずにjson.Unmarshalような関数を呼び出すことは_すでに_悪い習慣ですが、通常はdefer file.Close()代わりに悪い習慣とは見なされないということdefer func() { err = file.Close(); if err != nil { ... }; }() 、そして私たちはかなり簡単に違いを見分けることを学びました。 したがって、それは（おそらく）あなたの提案された変更に伴うでしょう。 私は当初、誰かがエラーを処理するつもりで無邪気にfoo := strconv.ParseFloat(bar, 64)を使用していると思いましたが、簡単に検討した結果、結局のところ問題ではないと思います。

@sirkon https://github.com/golang/go/issues/32825#issuecomment -507167388について：このような明らかに修飾されていないステートメントは、議論から除外してください。ここには場所がありません。 念のために言っておきますが、Goのアイデアの多くは、実際には60年代ではなく80年代のもの（パッケージ、個別のコンパイルなど）であり、多くははるかに若いものです（ゴルーチン、インターフェイス）。 これらのアイデアはまだ古いように見えるかもしれませんが、それらは時の試練に耐えてきました（少なくともCSが出回っているわずかな時間）。

@turtleDev https://github.com/golang/go/issues/32825#issuecomment -507231353について：Goは例外処理を行い、 panicとdeferとrecover -この用語にはGoにとって誤解を招くような意味合いが含まれているため、「例外処理」とは呼びません。 ただし、明確にするために、Goはtry-catchでraiseが実行できるすべてのことを実行できます（ try-catchとは対照的に、 deferを使用できるため）条件付き）。 ありがとう。

@sorenvonsarvort https://github.com/golang/go/issues/32825#issuecomment -507268293について：ケースごとに異なるエラー装飾が必要な場合は、 ifステートメントを使用してください。 デザインドキュメントをご覧ください。 この質問はこれまで何度も答えられてきました。 ありがとう。

@cstockton https://github.com/golang/go/issues/32825#issuecomment -507306652について：はい、そのようなメカニズムについて考えました。 具体的には、「テーブルをめくる」ことを考え、 tryを提供する代わりに、エラーハンドラーを宣言するhandle提供するだけです。 ハンドラーが存在する場合（そしてその場合のみ）、割り当てのLHSにerrを残すだけで、暗黙的にチェックされます（非表示のtry ）。 見た目は良いですが、完全に見えないので、大きな赤い旗です。 例外処理をコード内のあらゆる場所で明示的に表示する必要があります。 それがなければ、コードを読んでエラーチェックがどこで起こっているかを確認することはほとんど不可能です。

@griesemer明確にしてくれてありがとう。 しかし、パニックとリカバリーには異なるユースケースがあり、ほとんどの場合、プロダクションコードベースで見つけるのは非常に困難です。 そのため、フロー構造の制御は限られた量しかありません。 新しいコンストラクトを追加すると、returnのようなことを行うフローコンストラクトの新しいコントロールがあるため、その一貫性が失われます。

@ matthew-noken https://github.com/golang/go/issues/32825#issuecomment -507323973について：あなたは興味深いアイデアを提案しています。 デバッガーのウォッチポイントメカニズムに非常によく似ています。 答えなければならないいくつかの質問があります： onブロックは戻る必要がありますか（そうでなければスパゲッティコードの土地に入るので、私はそう思うでしょう）？ そのようなonステートメントを複数持つことはできますか？ on条件はどのくらい複雑になる可能性がありますか（割り当てごとに評価する必要があります）？ onステートメントで変数を一意に識別する必要があるため、任意の式を使用できないことに注意してください。 また、Goのややアナテマ： on構造は、他の場所で実行される目に見えないコードを意味します。

これをさらに詳しく調べたい場合は、他の場所（golang-nuts、または別の新しい提案）でこれについて議論することをお勧めします。 ありがとう。

@as https://github.com/golang/go/issues/32825#issuecomment -507345821：

ポインタ演算は、悪い、壊れたコードを簡単に書くことができるという前提で、Goから除外されました

実際には、ガベージコレクションが困難または不可能になるため、除外されました（もちろん、安全でないコードを作成することもできます）。 しかし、ここでより重要な点は、この決定を裏付ける具体的な証拠と経験があったということです。

ネストされたtryが普及または一般的になるという経験や証拠はまだありません。 ただし、 https： //github.com/golang/go/issues/32825#issuecomment-507358397を参照して

@turtleDev https://github.com/golang/go/issues/32825#issuecomment -507368167について： panicは_正確に_例外であり、遅延関数内のrecoverは本質的にcatch 。 Goでは例外を使用してコードを記述することはお勧めしないため、本番コードでは見つけるのが難しい場合があります。 それらは例外的な状況でのみ使用されるべきです。

制御フロー構造の数について：提案は、 tryが単なるシンタックスシュガーであり、他には何もないことを非常に明確にしています。

私はこのスレッドのこのスレッドの最近のコメントのいくつかに答えようとしました。 しかし、実際のtry号＃32437のtry提案に対する新しいコメントを続けましょう（今日の時点で再びロックが解除されました）。 この問題はleave err != nil alone議論のために予約しておいてください。 ありがとう。

@cstockton https://github.com/golang/go/issues/32825#issuecomment -507306652に関する別のコメント：これを実装した場合は、

    func f() int { ... }
    ...
    x := f()

に変更します

    func f() (int, error) { ... }

x := f()が突然、静かに大きく異なることを意味します。

@lparがすべてのgoリポジトリで実行しました。 結果はこの要点にあります： https ：

@ianlancetaylor私は実際、これはほとんどの場合非常にうまく機能し、より良いエラー報告を導入することによる影響をはるかに少なくすると感じています。 2つの主なケースの完全な例を考えてみましょう。最初に、呼び出し元がエラーを返します。

func f() int { ... }
func a() error {
    x := f() // if f() is updated to return an error, we get automatic error propagation by default
    ...
}

func b() {
    x := f() // if f() is updated to return an error, we get the same compiler error 
    // assignment mismatch: 1 variable but pkg.f returns 2 values
}

一般的なケースでは、これはこのアプローチの良い利点だと思います。これが問題を引き起こすコーナーケースは、すでに脆弱であると私は信じています。 本当に厄介であると私が考えることができるのは、ミューテックスをデッドロックすることだけです。

func (t *T) a() error {
   t.mu.Lock()
   x := f() // if f() is updated to return an error, we get automatic error propagation by default
   if x > 15 {
     t.mu.Unlock()
     return errors.New("t > 15")
   }
   ...
}

しかし、そのように記述されたコードは、有効なプログラム状態を持つために成功するために外部ライブラリ呼び出しに依存している場合、すでにデッドロックの影響を受けやすいと思います。 パニックを超えて存続できるスコープに格納されている場合、同じライブラリがNPEを介してランタイムパニックを引き起こすと、デッドロックが発生する可能性があります。 さらに、このようなコードを作成する主な動機は、ヒープ上に存在する延期者の取得原価です。 スタック上に存在するシングルディファーのパフォーマンスが向上しているため、このようなコードは実際には必要ありません。 このタイプのエラーの派生は簡単に修正できると思います。

最後に、ツールで「試行」の欠点をサポートするという議論のように、ここでも適用できます。 go-modulesの採用が増えていることを考えると、ユーザーの顔の前にそのような変更を明確に表示するために、「ライブラリアップグレードリンティング」ステップを注入する絶好の機会があります。

@griesemer

制御フロー構造の数について：提案は、tryが単なるシンタックスシュガーであり、他には何もないということは非常に明確です。

申し訳ありませんが、 tryは（Cのような）マクロにはならないので、事実上、エンドユーザーにとってはフローステートメントの別のコントロールにすぎません。

現時点では客観的な議論はないと思いますので、もっと良いエラー処理が必要かもしれないと認めますが、 tryは最善の解決策ではないかもしれません。

繰り返しますが、これらは私の意見であり、私はそれらを代表しているだけです。 Goチームは、これまで以上に多くのことを考えてきたと思います。

サイド：それは、この問題は、一方で1335 upvotesを持っていることを奇妙なとして私を打つtry提案（＃32437）のみ279 downvotesを持っています。 これら2つの提案は相互に排他的であるため、これに賛成する人々がtry提案に反対することで、コミュニティの感情がより明確になることを期待します。

@griesemer

エラー処理は状況ごとにすでに異なります。エラーを変更せずに返す場合、装飾されたエラーを返す場合、エラーに対処する場合、エラーを（正しく）無視する場合があります。

そこで同意しました、それだけは明らかです。

それらがすべて共有する唯一のこと（エラーを無視する場合を除く）は、 err != nilテストです（これはすでに複数の方法で実行できます）。 新しい言語機能がこれらすべてのケース（またはそれらの95％）をキャプチャするのは良いことですが、そのような構造は、すでに持っている他の制御構造と非直交的に干渉する可能性が非常に高くなります。 つまり、私たちが期待できる最善の方法は、これらのケースのいくつか（おそらく、20％、おそらく50％）を改善することです。

提案されたtry()ステートメントもifとreturnを非直交的に「干渉」するので、その議論は正しくないと思います。 ここの何人かの人々はまさにその理由でtry()を嫌います、しかし私は同意しません。 GoはOberonではなく、シンプルですがミニマルではありません。Goの方が実用的です。

私たちが同意しないのは、あなたが認めたように、使用法と適用性が限られており、 ifとreturnすでに正しく実行できる言語構造を気にすることは価値があるということです。 try()圧倒されて、まったく持っていたくないと思います。 リターンと直交していなくても、より強力で一般的に役立つtry()は、おそらくほとんどのGoプログラマーが望んでいるものです。

@beoran 、

あなたは「より強力な」「より一般的に役立つ」 try()が欲しいと書いた。

@griesemerは4つの状況に言及しました：

1. エラーを変更せずに返します
2. 装飾されたエラーを返す
3. エラーに基づいて行動する
4. エラーを無視する

try() 、設計により1を解決します。これは文字通りif err != nil { return ..., err }ショートカットです。

既存の言語構造は3と4を​​解決します。 if err != nil { ... }エラーに対処することはすでに可能であり、その場合、より簡潔な構造を見つけることは困難です。 _エラーはすでに無視できます。

これにより、2が残ります（装飾されたエラーを返します）。 try()提案では、deferステートメントを使用してエラーを装飾するか、各エラーを異なる方法で装飾する必要がある場合は、標準のif err != nil { ... }構造を使用することをお勧めします。

理由は提案のこの部分でよく説明されてい

この提案の最初の反復は、エラー処理の主要部分からの2つのアイデアに触発されました。これは、演算子ではなく組み込みを使用することと、新しいエラーハンドラ言語構造ではなくエラーを処理するための通常のGo関数です。 その投稿とは対照的に、エラーハンドラーには、問題を単純化するために固定関数シグネチャfunc(error) errorました。 エラーハンドラは、エラーが発生した場合、囲んでいる関数からtry返される直前に、 tryによって呼び出されます。 次に例を示します。

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

f := try(os.Open(filename), handler)              // handler will be called in error case

このアプローチでは、効率的なユーザー定義のエラーハンドラーを指定できましたが、明らかに正しい答えがない多くの質問も開かれました。ハンドラーが提供されているがnilの場合はどうなるでしょうか。 tryパニックになるべきですか、それとも存在しないエラーハンドラーとして扱うべきですか？ ハンドラーがnil以外のエラーで呼び出され、nilの結果を返した場合はどうなりますか？ これは、エラーが「キャンセル」されたことを意味しますか？ または、囲んでいる関数はnilエラーで戻る必要がありますか？ オプションのエラーハンドラーを許可すると、プログラマーが適切なエラー処理を完全に無視するようになるかどうかも明確ではありませんでした。 また、どこでも適切なエラー処理を行うのは簡単ですが、 try 1回発生するのを見逃します。 などなど。

次の反復でdefer 、エラーラッピングに

[...]

何らかの形で明示的に提供されたエラーハンドラー関数、またはその他の追加パラメーターを使用するのが良い考えであると将来的に判断した場合、その追加の引数をtry呼び出しに渡すことは簡単に可能です。

あなたはこの推論に同意しませんか？

私は提案のこの部分を知っていますが、それに同意しません。エラーハンドラーを渡すという考えのために質問が開かれたという事実は、そのような機能が必要ないという意味ではないからです。 それは、合理的な方法でそれらの質問に答えるためによく考えなければならないことを意味します。

さらに、今では、4つのエラーユースケースすべてをif err != nilステートメントで処理します。これは、広く理解されている、一貫性のあるGoイディオムです。 ケース1にtry()のみを使用し、場合によってはケース2にのみ、deferステートメントでエラーラッピングを実行するオーバーヘッドを気にしない場合は、エラー処理のコードがif分割されることを意味します。 try一貫性がなく、エラー処理が変更された場合は、一方と他方を切り替える必要があります。

すべての場合に使用できるtry()のより強力なバージョンでは、ほとんどの場合try()を使用でき、これがGoの新しい一貫したエラー処理イディオムになります。

ただし、現在のtry()では、十分に広く適用できるわけではなく、前述のエラー処理の不整合をコードベースに導入するのに十分な利便性が得られていません。 そのため、現在のtry()提案に圧倒され、何もしない方が良いと思います。

@beoranケース1と2は、関数からエラーを返すのが共通していると思います（それぞれ装飾なしとあり）が、ケース3と4は返しません（それぞれエラーに対処し、エラーを無視します）。 'try（） `の焦点はケース1と2にあると思います。

オプションのハンドラー関数を受け入れることにより、ケース1と2を処理するようにtry()プロポーザルを改善できるとしたらどうでしょうか。 もちろん、これには提案にリストされている質問に対する合理的な答えを見つける必要がありますが、それは扱いやすいようです。 そのようなものをサポートしますか？

ここに私がいます。 この場合、ユーザーにエラーをチェックしてもらいたい場合は、チェックされたエラー（チェックされた例外のようなもの）を追加する必要があります。 そうすれば、可能な限り明示的になり、ユーザーはすべてのエラーをチェックしていることがわかります。

真面目な話ですが、私がこれらの決定を下したのであれば、Kotlinの?演算子またはさびたunwrap()動作のようなものを再利用したいと思います。

これらのいずれかが改善されると思います。

getFile()?.getPath()?.toString()

あなたが取得する場所nil帰りに沿ってエラーが発生した場合または

get_file().unwrap().get_path().unwrap().lossy_to_string()

エラーが発生した場合、途中で爆発します。 Rustは、表現力豊かなmatch関数を使用して、エラーを徹底的に検索し、それぞれを個別に処理して、チェーンの上位にある種類の値を返すことで、2番目を処理します。

7/2/19に、NicolasGrillyの[email protected]は次のように書いています。

@beoranケース1と2は、共通してエラーを返すと思います。
機能（それぞれ装飾なしと装飾あり）、ケース3と4
しないでください（それぞれエラーに対処し、エラーを無視します）。 'try（） `だと思います
焦点はケース1と2にあります。

私の提案についてこれ以上の議論が見られないことに少しがっかりしています
「エラーリターン」の「リターン」部分である必要があること
「エラー」の部分ではなく、対処しました。

それならまた、もっと公式なアプローチに従うべきだったのかもしれません。 私
単に提案を作成するのが苦手で、私はあちこちに行く傾向があります
場所。

私の意見では、ケース1と2は、「失敗」コマンドの方が適しています。
（ある程度慣れた後）明確に示すキーワード
プログラムフローの変更であり、これは対象外です。
その完全な構文に関して不便な伝統。

しかし、それから続くのは、私たちがそれを好むかどうかにかかわらず、それです
最後の戻りパラメータとしての「err」の位置付けは間もなく
慣習ではなく法律になる。 それは多くの「意図しない」または
考慮に入れる必要のある「付随的な」結果。

最小限のものから
悲惨な、日和見的にのみ便乗するものもあります
提案。 私は個人的に注意を怠るでしょう、私はします
特にゴーチームとロバートが求めている理由を理解する
サポートと抵抗がそうであることが判明したことは間違いなく傷ついています
素晴らしい。

それは政治的イデオロギーの衝突です、おそらく私たちはたくさん掘り下げる必要があります
ガーデニングの注意が必要な本当のルーツを探すために、より深く。

@lootch tryが機能するために、エラーが最後の戻りパラメーターである必要があることに特に懸念がありますか？ それはすでに事実上の慣習ではありませんか？

（余談ですが、私たちは抵抗について「傷つけられている」わけではありません。大部分は特大の反応に憤慨しています。）

@griesemerは、

たくさんのGoを書いたことがあるという簡単なコメントを書きたいと思います（私は2009年の最初の公開リリースからGoを使用しています-私のgithubを参照してください）エラー処理に関する人間工学の改善を

私はこの数年前に十分にイライラしました。私は実際にパニックの周りに砂糖を書き、それらが（ほとんど）チェックされていない例外のように機能できるように回復しました： https ：

エラー状態を伝播する非常に冗長であるが役に立たない方法を維持することを人々が熱心に主張しているのはおかしなことに思えます。 私は自分のコード（および他のコード）に実際のバグを書き、発見しました。そこでは、人々がif err != nil条件を台無しにして、バグを作成しました。 これらのバグが書き込まれる理由は実際にはありません。 静的チェックはこれらのバグを助けることはできますが、なくすことはできません。

エラー処理に関する人間工学を改善するための提案を支持します。

提案プロセスは、 https： //golang.org/s/proposal「ProposedChangestoGo」を引用するためのものです。
この問題は変更を提案していないので、実際には少しカテゴリエラーです。
誰かが「選択をそのままにしておく」というタイトルの提案を提出した場合、提案ではないとしてそれを閉じるだけです。

しかし、実際には、この問題は＃32437のような他の問題の議論の延長に過ぎないので、「何もしない」ことを議論するのに適した場所として開いたままにしておきます。

ここに特定の決定はなく、メタ決定であるということを示すために、提案-保留とマークしました。

サイド： tryプロポーザル（＃32437）が279の反対票しか持っていないのに、この問題が1335の賛成票を持っているのは奇妙だと思います。

トライプロポーザルは気付いた頃にはロックされていたので、反対票を投じることはできませんでした。 それが、この提案が最初に入力された理由でもあると思います。

7/2/19に、RobertGriesemerの[email protected]は次のように書いています。

@lootch最後にする必要のあるエラーについて特に懸念がありますか
tryが機能するためのパラメータを返しますか？ それはすでに事実上のことではありません
大会？

それが「事実上の」石に投げ込まれたら、
そのドアを開けて、「エラー」をオプションの特別なものにする必要があります
引数の型とそれを受け入れる、なぜならそこにあるすべての正しい結果のために
多くの場合、多くの間違ったものであり、
特別な方法で対処しました。

「return」ステートメントを調査する必要があるという考えがあれば
より深く（そしてtryの提案はそのことを示唆しているようです
方向）の場合、エラー条件は「単なる値ではなく、
Goのアプローチは、
日付ですが、それでもカードの家です。

私はGoの巧妙なトリックのいくつかを嫌がるユーザーです（私は持っています
x ++とx--は機能しないと他の場所で述べました-ほとんどの場合、私はスリップします
時々アップ-私のコードでは）だから「試してみる」は私にとってそれらの1つのままです、
しかし、私はその導入に原則的に反対しません、私はただ感じます
そんなに多くのことが言われました、そしてそれでもすべての可能な欠点はそうではないかもしれません
明らかにされた（私が見ているものの意図しない結果
最終的な政治的決定）。 それをテストするのは良いかもしれません
または悪い。

私が見ているのは、パニック/回復が悪いラップとそれの不正を手に入れたということです
私たちを悩ませるために戻ってきています。 繰り返しますが、私はまだどちらも使用していません。
私は瓶の中で最も鋭いクッキーではないので、私がしなければならない日を恐れます
とても難しいと思いますが、パニック/回復が奨励されていました
それが適切であるまれな機会のために（それらのどれもによって扱われません
エラーが戻ってくるだけであるという彼の素晴らしいプレゼンテーションでのロブ・パイク
値、私が正しく思い出せば）、それはすべてのことに対してはるかに明確になるでしょう
Goはすでにエラーを処理しているだけでなく、必要なしに期待できます
それを超えて利用可能な可能なオプションの沼を探索する
境界。

とは言うものの、試してみるのは理にかなっています。
すべて、オプション機能。 しかし、1つの副作用はこれが何であるかです
交換とは：「事実上の」結果はどうなるか
「エラー」型の引数を持つように強制的なエラー処理関数
戻りパラメータリストの最後にありますか？ それはどのように変化しますか
「エラーは単なる価値である」という認識？ それはどのように適合しますか
今ではもっと類似した「コンマOK」パラダイム？ これは他に何をしますか
新しい原則は生じますか？

何より、このモグラヒルでできている山は
Goが人生を変えるマイルストーンに到達したことを示します。 ほとんど
確かに、2013年に真実だった仮定は、もはやそうではないかもしれません
所有。 それは誰にとってもニュースではありませんが、Go2が
これまでのようにGo1との下位互換性があることはそれほど素晴らしいことではありません
あまりにもしっかりと提案されました（私の意見では）。

@lootch詳細な回答ありがとうございます。 確かに、既存の言語を下位互換性のある方法で拡張することは非常に難しいので、その下位互換性が必要ない場合は、おそらく別の方法で行う可能性があることに同意します。 間もなく（モジュールが一般的になると）、厳密な下位互換性を必要としない言語変更を行うことができるようになります。

あなたが言うように、 tryはオプションのメカニズムであり、繰り返す価値があると思いますが、その周りのすべてのフープラにもかかわらず、既存のGo機能を使用して簡単に説明できる非常に単純なメカニズムです。 t tryをGo ourselfの関数として記述します（さらに言えば、ジェネリックスも役に立ちません）。 可能であれば、既存のコードでエラー処理を行うためにtryなどのヘルパー関数を使用することは非常に一般的であると確信しています。 結局のところ、エラーが値であるというRob Pikeの話は、まさにエラーを伴うプログラミングです。

非常にマイナーなヘルパー関数を追加することに関して、誰もが自由に無視できるほどの騒ぎがあることは、私にとってまだ非常に驚きですが、人々は、特定のスタイルを強く示唆するon errorなどの重要な言語変更を真剣に考えています。言語でのエラー処理の。

ご意見ありがとうございます。 これはすべて非常に興味深いものです。

この提案がそれを議論するのに適切な場所であるかどうかはわかりませんが、このスレッドのtryキーワードについてはすでに活発な議論が行われているので、今のところトピックについて検討します:)

Googleの人々は、内部のGolangリポジトリにtryキーワードを実装し、その後、既存のGoogleコードベースをそのキーワードを使用するように変換することをいとわないのではないかと思います。 内部のみに保持することで、簡単に元に戻すことができます（つまり、コミュニティ全体ではなく、単一の会社に負担がかかります）。

これにより、実際の高スロットコードベースでこの機能に関する小さなケーススタディを行うことができます。 Facebookは過去にPHPの機能と同様のことを行っており、そのようにして、コミュニティ全体に提案する前に特定の機能を微調整することができました。

tryキーワードが実際にどのように使用され、実際にどのような価値が追加されたかについてのケーススタディを作成する場合、説得力のあるケースを提供できます。 それが（仮想的に）現実世界の価値を提供しないのであれば、それも知っておく価値があります。 紙の上では本当に見栄えがするものの、実際にはうまくいかない場合があります。その逆も同様です。

@Freeaqingme tryがstdライブラリでどのように表示されるかを示す暫定CLをすでに作成しています： https ：

また、コードベースでtryhardして、レポートを返すことをお勧めします。

ありがとう。

@griesemer私は自分自身を明確にしていないかもしれません。 Googleは独自のGoビルドを社内で使用していると思います。 私の提案は、上記でリンクしたパッチを内部のGoogleビルドに適用してから、Googleコードベース（stdlibだけでなく、特にGoで記述された内部プロジェクト）を変換することです。 Googleのエンジニアが実際の状況で数か月間使用すると、実際にどのように機能するかについての優れた洞察が得られます。

もちろん、自分で適用して、自分のコードベースで使用することもできます（私もそうかもしれません）。 しかし、私は比較的小さなコードベースを持つ単一の開発者であるため、多くのGoogle従業員がそれを使用する場合、これは代表的なものではありません。

個人的には、私はまだこの機能についてのフェンスにいます。 一方で、毎回数回のキーストロークを節約できるという事実に感謝しています。 しかし、時々私は怠惰になるかもしれません（結局私は人間です）、そして私ができるだけ多くのtryステートメントをネストするだけです。 この機能があれば、もう少し規律を身につけることができます。 しかし、私がそうだったとしても、コードベースがこのキーワードに苦しんでいる間（デバッグ可能性、それらのライブラリの拡張性の観点から）、外部ライブラリがこのキーワードを乱用/乱用する可能性があります。

@Freeaqingme了解しました。 確かに、内部リポジトリに対してtryを実行できます。 変換して元に戻すことができるかどうかはわかりません。ここにはかなりのコストがかかります。 また、内部の詳細については報告できないため、この実験については集計（統計）でしか報告できませんでした。 つまり、コミュニティには私たちの主張を検証する簡単な方法がありません。 最後に、Googleのコードベースは代表的なものではない可能性があります。

しかし、感謝します。

@griesemer費用のかかる作業になる可能性があることを感謝します。 その場合、私はそれをしません。 トライハードプロジェクトを適用するだけの場合は、コストが制限される可能性があります。 しかし、実際には、それはGoogle社員（私はそうではありません）が判断するためのものです。

個々のGoogleプロジェクトや内部インフラストラクチャについて報告することはできないとのことですが。 ただし、おそらくいくつかの逸話を共有することができます。 しかし、私が個人的にもっと価値があると思うのは、それがどのように機能したかについて報告しているGoogle社員です。 詳細に立ち入ることなく、「Xを期待していましたが、AやBIのようなケースに遭遇したとき、Yが見つかった」などのステートメントは非常に価値があります。 そのような種類のレポートを検証する必要はありません。

最後に、Googleのコードベースは代表的なものではない可能性があります。

そうかもしれないし、そうでないかもしれない。 しかし、Googleで働いている人はたくさんいるので、コードベースのほとんどは、1人の個人がどのように記述したかではなく、多くの異なる貢献者（従業員）の貢献の集大成であると思います。 その点で、私は物事が得ることができるのと同じくらい代表的なものになることを期待しています。 100％代表的なコードベースのようなものはおそらくないでしょう。

より良い解決策が見つかるまで、 tryは私たちが探していたものではありません。 これに対してバイアスアクションを実行する必要はありません。時間をかけてGoAuthorsを実行してください。 私が毎日世界中のgopherと話している限り、Goコミュニティの大多数はtry提案のATMを受け入れていないと強く信じています。

新しい構文を導入するということは、誰もがGoバージョンをアップグレードする必要があることを意味します。 私のワークフローはgo getものをコマンドラインから使用できるという事実に基づいているため、私はまだGo 1.10を使用しています（私のGOPATHは私のPATH ） 。 最近、モジュールを使用する他の誰かのライブラリをgo getしようとしたときに問題が発生しました。 .../v2が利用できないというエラーが発生しました。 これは、コードがすでに分割されていることを意味します（Python 2と3を考えてみてください）。 私にとって、Go1.11の前とGo1.11の後の世界があります。 これは非常に煩わしく、Goでのエラー処理と同様に機能するものに新しい構文を導入することは、良いトレードオフではありません。 それはより多くの断片化をもたらします。

7/4/19で、gonutz [email protected]は書きました：

新しい構文の導入は、誰もがGoをアップグレードする必要があることを意味します
バージョン。 私のワークフローは事実に基づいているため、私はまだGo1.10を使用しています
go getものをコマンドラインから使用できること（my
GOPATHは私のPATH ）。 最近、 go getしようとしたときに問題が発生しました
モジュールを使用する他の誰かのライブラリ。 .../v2が
利用不可。 これは、コードがすでに分割されていることを意味します（考えてみてください）
Python 2および3）。 私にとって、Go1.11の前とGo1.11の後の世界があります。
これは非常に煩わしく、機能するものに新しい構文を導入します
Goでのエラー処理と同様に、良いトレードオフではありません。 それ
より多くの断片化を導入します。

それが慰めであるならば、私は対してまったく同じ立場にいます
Goモジュール。 慣れるための時間と機会が見つかりませんでした
彼らと一緒なので、私もGo1.10にこだわっています。 多分それはあるべきです
持つ価値のある調査。

ルシオ。

-
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください。
https://github.com/golang/go/issues/32825#issuecomment -508372318

-
ルシオデレ
2 Piet Retief St
ケステル（東部自由州）
9860南アフリカ

Ph。：+27 58 653 1433
セル：+27 83 251 5824
FAX：+27 58 653 1435

私は新しいgolang開発者です（まだgoについて学んでいます）。 エラーを管理しやすいので、現在のエラー処理は良いと思います。 Android開発者として、私はtry-catchがgolangのif err != nil{ }よりもエラーを管理するのが難しいと思います。 そして、明示的なエラー処理は、暗黙的なエラー処理よりも常に優れていると思います。

PS。 私の言語でごめんなさい。

壊れてない…。

ミームが大好き、 @ Daniel1984 :-)

ちなみに、 try提案では、 if err != nilはそのままになります。 それはあなたにそれが理にかなっている追加のオプションを与えるだけです。

私はtryを含めるべきではないと考えています。 try含めることについて：

プロ

• プログラマーは、キーストロークの数を減らします。
• プログラマーは、マクロの現在の関数から戻るための省略形を持つことができます。
• 必須ではありません。
• 一般的に使用されます。
• 魔法がどこで起こっているかは明らかです（Javaのthrowsとは異なります）。
• nil小切手の海を見ているときに、目が釉薬をかけなくなりました。
• 単純な実装で最適に機能します。

短所

• tryは、既存の操作に重複するメソッドを追加します。
• tryが現在の関数から戻るのは予想外であり、別名、より魔法のようなものです。
• エラーチェックに不整合が追加されます。
• Goの経験がないプログラマーは理解できません。
• エラー処理は変更されません。
• 明確度が低い（関数の戻り値と式の値の不一致）。
• tryで何が起こっているのかを言葉で説明することすら難しい。

@griesemerそれはまさに私が好きではないものです。 物事は単純でなければなりません。同じことを達成するための2つの方法があるだけで、言語に複雑さを加えたくありません。 このif err != nil冗長性を回避するためのパターンがあります。 https://www.ardanlabs.com/blog/2019/07/an-open-letter-to-the-go-team-about-try.html

Go2提案＃32437は、言語に新しい構文を追加して、 if err != nil { return ... }ボイラープレートの煩わしさを軽減します。

さまざまな代替案があります。元の提案は普遍的に愛されていないため、＃32804と＃32811です。

ミックスに別の選択肢を投げるには：そのままにしてみませんか？

if err != nil構造の明示的な性質が好きになったので、このために新しい構文が必要な理由がわかりません。 本当にそんなに悪いの？

非常にこれ。 明示的なコードは正しいコードです。 例外ハンドラーで私が見た恐怖は、そのひどい読めない構造から永遠に離れるのに十分です。

人々がコメントするだけで、大きな遅れがあるようです
今、それが新鮮であるという印象を得るのは仕方がありませんでした
彼らへのニュース。

それも考慮に入れる必要があります。 ブドウの木は明らかにそうではありません
人が考えるかもしれないように速い。

ルシオ。

そして、gofmtを変更して、単純なハンドボールとエラーが発生するまでの単一行のifステートメントを許可します。
関数を呼び出します。 それは多くの混乱を取り除くでしょう。

それ以外の：

err = myFunction（）
if err！= nil {
エラーを返す
}

許可する：

err = myFunction（）
if err！= nil {return err}

ちなみに、tryプロポーザルはerr！= nilだけの場合は終了します。 それはあなたにそれが理にかなっている追加のオプションを与えるだけです。

この正確な正当化は、Goがさらに別のC ++、C＃、Scala、Kotlinなどになる方法です。「使いたくない場合は使用する必要はありません」は、機能が肥大化した言語を作成する方法です。

編集-これは間違った方法に出くわした可能性があります。 tryがGoを機能の肥大化した言語に変えると言っているのではありません。 ここでの正当化には少し欠陥があると言っています

@deanveloper 「try」でエラーの動作を理解するのが難しい例がはっきりとあります。
https://github.com/golang/go/issues/32437#issuecomment -498932961

少し繰り返しますが、OPに同意します。
さらに、提案されたすべての代替案は、役に立たない複雑さをもたらします。

スコープ内に1行しかない場合は、中括弧を省略すると便利です。

@怒る

これは、コードがすでに分割されていることを意味します（Python 2と3を考えてみてください）。 私にとって、Go1.11の前とGo1.11の後の世界があります。

私は長い間Pythonプログラマーであり、Goモジュールに関してあなたが言及したとされる「分割」は、Python2からPython3への移行の惨事に匹敵するものではありません。

これは非常に煩わしく、Goでのエラー処理と同様に機能するものに新しい構文を導入することは、良いトレードオフではありません。 それはより多くの断片化をもたらします。

tryは、プロポーザルに組み込まれている関数です。 完全な下位互換性があります。 コードがすでにtryを識別子として使用している場合、その識別子はtryビルトインをシャドウイングします。

@pongsatornw

エラーを管理しやすいので、現在のエラー処理は良いと思います。 Android開発者として、golangでerr！= nil {}を実行する場合よりも、try-catchでエラーを管理するのは難しいと思います。 そして、明示的なエラー処理は、暗黙的なエラー処理よりも常に優れていると思います。

提案を完全に読みましたか？ tryは、 if err != nil { return ..., err }繰り返しを除外するのに役立つ組み込み関数です。 Goでのエラー処理の一般的なロジックは同じままです。 それはまだ明示的であり、エラーは依然として値であり、try-catch（別名例外）はありません。

@kroppt

• tryは、既存の操作に重複するメソッドを追加します。

tryは、反復的なコードを因数分解しているだけです。 appendと同じです。 スライスに要素を追加するたびに自分で書くことができますが、 appendを呼び出す方が簡単です。

• エラーチェックに不整合が追加されます。

何をするかに応じて、 [...:...]を使用してスライスを「手動で」操作することも、 appendを使用することもできます。 矛盾はありません。 これらは、タスクごとに異なるツールです。 エラーについても同じですが、手元のタスクに応じて、プレーンなif err != nil { ... }またはtryを使用します。

• tryが現在の関数から戻るのは予想外であり、別名、より魔法です。

新品なので意外です。 使うほど慣れてきます。 そして、私はそれが魔法だとは思いません。 tryの仕様は非常に簡単です。

• Goの経験がないプログラマーは理解できません。
• tryで何が起こっているのかを言葉で説明することすら難しい。

Goの経験がないプログラマーはchan 、 defer 、 'go , iota ,パニック,回復,理解しません, type assertions, and many other things either without reading the documentation. try`は、これのほとんどに比べて簡単です。

• エラー処理は変更されません。

if err != nilを放っておくように頼むgophersによると、それは良いことかもしれません;-)

@marcopeereboom

明示的なコードは正しいコードです。 例外ハンドラーで私が見た恐怖は、そのひどい読めない構造から永遠に離れるのに十分です。

tryは、例外処理とはまったく関係ありません。 提案全体を読みましたか？ たとえば、JavaやPythonのような例外処理に匹敵するものはありません。 tryは明示的です。 エラーは関数のシグネチャに記載する必要があります。 エラーは、コールサイトで処理する必要があります。 スタックの巻き戻しはありません。 NS。

@ gale93

スコープ内に1行しかない場合は、中括弧を省略すると便利です。

ほとんどのgopherは同じ考えを持っていたと思います。私は、IssueTrackerで同様の提案を何度も読みました。 しかし、それはtryよりもはるかに大きな変更です。 ifステートメントだけでこれを行うのは合理的ではありません。 したがって、ブロックが受け入れられるすべての場所でこれを変更する必要があります。 {がブロックの開始をマークしない場合、条件式の終了を区切る方法を指定する必要があります。 文法、パーサー、gofmtなどを更新する必要があります。これにより、言語の表面が完全に変わります。

@ngrilly
節度を保ち、言語をシンプルに保つことが重要です。

あなたが使用した議論のいくつかは、仕様への大幅な変更を正当化する可能性があります。 ここには良い点だけではありません。

私は、それが助けになるか害を及ぼすかということに基づいて決定を評価していますが、必ずしも特定の哲学を完全に制定しているわけではありません。 仕様の一部がgoが設立された特定の原則に違反していることは正しいですが、それはすべて節度に関するものです。 この変更は、ネガティブを許容するのに十分なプラスの影響を私に与えません。

こんにちは@kroppt 、

言語をシンプルに保つことは重要です

私は同意し、私たち全員がこれに取り組んでいると思います。

私は、それが助けになるか害を及ぼすかということに基づいて決定を評価していますが、必ずしも特定の哲学を完全に制定しているわけではありません。

私たちは皆、そのメリットとコストに基づいてtryを評価していると思います。 議論は、これらの利点とコストに関する事実に基づくコンセンサスを定義して見つけることについてです。これは、以前のコメントで私がやろうとしたことです。

仕様の一部が、goが設立された特定の原則に違反していることは正しいです。

過去数年間、私はGoチームがGoとそのデザインについて公開したほとんどすべてを読んでいますが、Inはあなたが何を意味するのか理解していません。 try提案がGoの基本原則に違反しているとは思いません。

@ngrilly
https://talks.golang.org/2012/splash.articleは、 go違いの背後にあるいくつかの概念、とりわけ明快さと単純さについて説明しています。 これは、私たちの一部がこの新しい変更で目にする対立だと思います。 簡単ですが、あまり明確ではありません。 私には、単純さの向上は、明快さの喪失よりも小さいように思われます。 多分私は間違っていて、ただ用心深いです。

@kropptこの記事を何十回も読んだことがあります;-) tryがコードを難読化するという考えに同意しません。 tryは、反復コードを因数分解するために使用される単なる組み込み関数です。 私たちはプログラマーとして常にそれを行っています。 繰り返しパターンを特定するときは、新しい関数でそれを除外します。 そうしないと、すべてのコードがインライン化された1つの長いmain（）関数が作成されます。

@ngrilly
あなたが説明していることは私の「プロ」セクションにあります：

• プログラマーは、キーストロークの数を減らします。
• プログラマーは、マクロの現在の関数から戻るための省略形を持つことができます。
• nil小切手の海を見ているときに、目が釉薬をかけなくなりました。

繰り返しになりますが、ここで原則を普遍的に適用していないのに、原則の普遍的な適用について言及する意味はありません。

tryがコードを難読化するという考えに同意しません

変更のポイントは、コードを難読化/非表示/簡略化/表現することです。そうしないと、元のエラーチェックブロックが表示されます。 問題は、それが意味をあまり明確にしないかどうかです。

go元々、明快さを損なうのではなく、貢献するという点で、シンプルさの素晴らしいバランスをとっていたと思います。 彼らがどのようにそれをしたかを説明することはできませんが、私の意見ではtryは説明していません。

冗長性を問題と見なすべきではないと思います。 コードは人間が読んで理解する必要があります—その時間はコンピューターよりも高価です—そして_理解_は困難で時間のかかる部分になる傾向があります。

goエラー処理のインデント構造は、何が起こっているのかを追跡するのに役立ちます。 すべてのエラーチェックは明示的です。 ほとんどの未処理のエラーも明示的です。 これにより、コードがすぐに理解できるようになります。

また、 if err != nilチェックは面倒に思えるかもしれませんが、実際にタイプする必要はないと思います。 私は自分の編集者にそれをやらせるだけです。

@kroppt

変更のポイントは、コードを難読化/非表示/簡略化/表現することです。そうしないと、元のエラーチェックブロックが表示されます。

ただし、この引数は任意の関数呼び出しに使用できます。 strings.HasPrefix("foobar", "foo")を呼び出すと、コードが難読化されますか？ l := len("foo"); len("foobar") >= l && s[0:l] == "foo"書いたり読んだりしますか？

@rossmcf

すべてのエラーチェックは明示的です。

tryはまだ明示的にエラーをチェックしています。 それは試練の存在意義です。

また、err！= nilチェックは面倒に思えるかもしれませんが、実際に入力する必要はないと思います。

入力するのは面倒ではありません。 どこにでも同じ3行があると、読むのが面倒です。 これは繰り返しであり、プログラマーとしての私たちは通常、これらを除外する傾向があります。 たぶんtryは他の欠点がありますが、これは私が思うにそうではありません。

tryはまだ明示的にエラーをチェックしています
try抽象化とstrings.HasPrefixの違いは、 try暗黙的に返されることです。
goコードを読むとき、実行フローは次のようになるまで関数内にとどまることがわかります。

• 戻り型なしで関数の閉じ括弧を読む
• キーワードreturn 、 panic読む
• syscall.Exit(code)読む
  tryでは、同じ方法でコードを読み取ることができませんでした。 行を視覚的にスキャンして「return」ステートメントがゼロであることを確認しても、「これらの行がすべて実行されるか、1つのブロックになるか、プログラムが終了する」という意味ではなくなります。

@ngrilly投稿FYIで複数の人に返信できます。数時間で10件の返信があり、一度に5件の返信があると、ディスカッションをフォローするのが難しくなります。 いくつかの誤謬を除いてあなたの投稿を読んだ後、私は試してみることの利点を説明する新しい具体的な議論が形成されているのを見たことがありません。 if err != nil入力を防ぐという1つの利点があります。 これには、リソースをリーク簡潔でないコードの記述機能、そして最悪の場合、tryのネストが可能になるという犠牲が伴います。

提案者によって形成された仕様と議論は誤解を招くと思います。現在、最悪の例を示すことなく、最良の例のみを提供しています。 上記のマイナスの欠点や潜在的な問題を緩和する要素については、評価も言及もされていません。 それは、tryの実装を提案され実証された使用法に制限しない理由を正当化するものではありません。 ツールtryhard主観せずに、一部の人々に優れた審美性を提供し、よりコンパクトなコードを示すために使用されているtrytoohardツールをすることを示しているもののすべての機能は、それが何ができるか、例えば、深くネストされた試みステートメント。 最後に、名前自体は例外を除いてプログラミングの世界で遍在的に関連付けられており、ネスト可能でエラーに関連付けられ、無関係の回復とパニックの組み込みとして隣接して配置され、物事が単に場違いに見えるようにします。 私は、Goの作者がもっと良いものを考え出す能力を信じ、信頼しています。

ここでは、提案者からの返信で逆流していると思われる単一の付加価値で正当化するにはコストがかかりすぎます。「 if err != nilと入力する必要がなくなりました」-エラーとともに熱心に防御され、根付いているものは次のとおりです。 Goコミュニティ全体による価値観。 if err != nilを使用して記述されたコードは最大10年になります。これは、最も注目すべき技術の進歩（docker、k8sなど）のいくつかが同時に使用され、すべて大成功を収めています。

if err != nil締めくくるのは、ビルトインで隠れることの負担ではありませんが、言語の成功の核となる要素として私たち全員が認識すべきことです。 それが負担であると私たちが集合的に受け入れたとしても、それを取り除くための基準は高く、妥協のないものでなければなりません。 今のところ、試行のあまりにも多くの側面が妥協です。

どちらの方法が簡単かについては意見がありますが、それは意見です。 与えられた試行は単純であり、現在の明示的なチェックは単純です。 どちらの方法も簡単です。 私にとっての問題は、特定のコードのリーダーとライターの両方の認知的負荷が増加することです。 今、両方が物事を行うために複数の方法を解釈する必要があります。 そして、ライターは、作業中のパッケージやプロジェクトの他の部分とは異なる方法で物事を行う方法や、物事を行うリスクを選択する必要があります。 明示的なチェックを置き換えようとすると、解析する別のこととして暗黙のリターンがあるため、認知的負荷が増加します。

_そのすべてを少し脇に置いて、エラーを処理する2つの同じように単純な方法があることを考えると、まだ問題があります。_単純はもはや簡単ではありません。 そして、それは、回避するように設計されたすべてのものへの扉を開きます。

このようなものを追加するための基準ははるかに高く、フィールドからのデータでより良いことを証明するために長い間実験的である必要があります。

@cstockton

投稿FYIで複数の人に返信できます。数時間で10件の返信があり、一度に5件の返信があると、ディスカッションをフォローするのが難しくなります。

Ianは、 7日前に、このディスカッションをgolang-nutsに移動する

@therealplato

try抽象化とstrings.HasPrefixの違いは、tryが暗黙的に戻ることです。

それは本当だ。 関数を読んで「終了」ポイントを探すときは、return、panic、log.Panic、os.Exit、log.Fatalなどを探して試してみる必要があります。 それはそのような問題ですか？ 関数内の出口点の数は同じままで、試行の有無にかかわらず、明示的にマークされます。

キーワードを読むリターン、パニック

パニックはキーワードではありません。 組み込み関数です。 おそらく私たちの誰よりも言語デザインに精通しているGoチームの提案を批判するのであれば、少なくとも、物事を適切に定義することを支持する必要があります。 😉

関数を読んで「終了」ポイントを探すときは、return、panic、log.Panic、os.Exit、log.Fatalなどを探して試してみる必要があります。 それはそのような問題ですか？

tryは、式が表示される場所であればどこにでも文字通り表示される可能性があるため、これは問題です。 Goのすべての出口点は、単一のステートメントとしてのみ発生する可能性があります。式として表示できるのはtryだけです。

@ngrilly

Ianは、7日前に、このディスカッションをgolang-nutsに移動することを提案しました（特定のコメントに返信する方法もスレッドもありません）。この提案は、ディスカッションが「公式」であることを確認するために却下されました。 私たちは私たちが尋ねたものを持っています。

メッセージを開始します

@ user1
返信1

@ user2
返信2

終了メッセージ

これが意味したことです。

@cstockton

if err！= nilの入力を防ぐという1つの利点があります。

tryは、 if err != nilだけでなく、 if err != nil { return ..., err } （3行でフォーマット）の繰り​​返しの入力と読み取りを防ぎます。

これには、リソースをリークする新しい方法の導入、簡潔でないコードの記述機能、そして最悪の場合、試行のネストが可能になるという犠牲が伴います。

あなたが言及したリソースリークのリスクは、 vetとlintで防ぐことができます。

「簡潔でないコード」については、 try要点はもっと簡潔なコードを書くことなので、私はあなたの議論を理解していません。

過度の関数呼び出しのネストのリスクは、 try固有のものではありません。 関数呼び出しは、過度にネストされる可能性があります。 いつものように、コードレビューとリンティングが役立ちます。

提案者によって形成された仕様と議論は誤解を招くと思います。現在、最悪の例を示すことなく、最良の例のみを提供しています。

たぶん、この気持ちは相互です。 私たちはみんな素敵なゴーファーです。 価値判断に陥らないようにしましょう;-)

提案者からの返信で逆流しているのがわかります：「err！= nilの場合は入力する必要がなくなりました」

繰り返しますが、 l := len("foo"); len("foobar") >= l && s[0:l] == "foo"と入力する必要はありません。
代わりにstrings.HasPrefix("foobar", "foo")を使用できます。
tryとどう違うのですか？
以前に読んだように、 checkという名前の「制限付き」 tryを受け入れ、ネストを禁止します。

if err！= nilを使用して記述されたコードは最大10年になります。これは、最も注目すべき技術の進歩（docker、k8s、...）のいくつかが同時に使用され、すべて大成功を収めています。

また、C、C ++、Javaなどで記述された優れたコードもたくさんあります。この一連の推論では、Goはありません。

Goでのエラー処理に関するディスカッションを読んだとき、 try提案に関して全員が同じページにいるとは思わなかったので、 tryがどのようにできるかを示すブログ投稿を書くことにしました。使用する： https ：

Redditに関する関連ディスカッション： https ：

この問題がtryに反していることは知っていますが、私の投稿がいくつかの新しい視点をもたらすことを願っています:)

Goは立ち往生していて、魔法の、または単純なアイデアのための論理の間で苦労しています。

長所：

• ボイラープレートを減らす
• 単純
• 他の言語の中でも既存のパターン
• オプション

短所：

• 学習曲線
• 根底にある魔法
• 新しい種類のバグ
• Goは意見があり、 if != nil実用的ですが、 try使用することもできます。

私はこのコミュニティ、特にのように感じます。 ここでは、Go Survey ^[1]で投票された人々とは異なります。
有権者はこれを主な関心事として選択せず、将来の検討に任せるかもしれません。
しかし、その配置のために影響があると見なされました。

IMO、言語機能の追加は古く、最新のプログラミング方法では、エディターに機能を追加しています。つまり、エメットまたは言語スニペット、コードの折りたたみと色付け、リファクタリングとフォーマット、デバッグとテスト、エラーの解決策の提案、godocまたはスタックオーバーフローからの引用です。 、ソースコードの上にUIを置き、ソースコードを冗長のままにします
^{_{コードはif err != nilをtry折りたたむ}}

@ngrilly

tryは、err！= nilの場合だけでなく、if err！= nil {return ...、err}（3行でフォーマット）の繰り​​返しの入力と読み取りを防ぎます。

「err！= nilの場合、入力できなくなる」と言っているのは、入力したコードも読んだことを完全に忘れてしまったことを意味していると思いますか？

あなたが言及したリソースリークのリスクは、獣医とリントで防ぐことができます。

ここで、獣医とリントが合理的な選択肢ではないと感じる理由についての議論をリンクしました。

「簡潔でないコード」については、もっと簡潔なコードを書くことがポイントなので、あなたの主張は理解できません。

はい、「簡潔でないコードを

過度の関数呼び出しの入れ子のリスクは、試行する特定のものではありません。 関数呼び出しは、過度にネストされる可能性があります。 いつものように、コードレビューとリンティングが役立ちます。

興味深いことに、実際にこれを分解してみましょう。

1）過度の関数呼び出しの入れ子のリスクは、試行する特定のものではありません。

はい、ここの誰もが関数がどのように機能するかを理解しています。

2）関数呼び出しは過度にネストされる可能性があります。

はい、ここの誰もが関数がどのように機能するかを理解しています。

3）いつものように、コードレビューとリンティングが役立ちます。

はい、あなたはすでにlint引数を作成しました。「コードレビュー引数」は、私があなたにリンクです。

たぶん、この気持ちは相互です。 私たちはみんな素敵なゴーファーです。 価値判断に陥らないようにしましょう;-)

分かりませんか？ この提案には、実装が提供する完全な機能の例はなく、意図された使用法のみが含まれています。 提案の影響を測定するために使用されるtryhardツールは、最も限定的で合理的な形式でtryを使用しますが、これは単純な事実です。

繰り返しますが、l：= len（ "foo"）;と入力する必要はありません。 len（ "foobar"）> = l && s [0：l] == "foo"。
代わりにstrings.HasPrefix（ "foobar"、 "foo"）を使用できます。
試してみるとどう違うの？

私はそれぞれの反対の見方から位置を抽出するために最善を尽くします、さもなければ私はそれを解体するための議論を形成することができません。 ここでは本当に見えません、ごめんなさい。 私はこれを私がそれを理解できる唯一の方法、つまり文字通りに解釈するつもりです。

（ strings.HasPrefix ）はtryどう違うのですか？

文字列.HasPrefix

func HasPrefix

func HasPrefix（s、プレフィックス文字列）bool

HasPrefixは、文字列sがプレフィックスで始まるかどうかをテストします。

試す

func tryは、try withsignature（擬似コード）と呼ばれる新しい関数のような組み込み関数です。

func try(expr) (T1, T2, … Tn)

ここで、exprは、タイプT1、T2、... Tnのn + 1の結果値と、最後の値のエラーを生成する着信引数式（通常は関数呼び出し）を表します。 exprが単一の値（nは0）と評価される場合、その値はエラー型である必要があり、tryは結果を返しません。 型エラーの最後の値を生成しない式でtryを呼び出すと、コンパイル時エラーが発生します。

tryビルトインは、最後の結果がエラー型である場合に、少なくとも1つの結果パラメーターを持つ関数内でのみ使用できます。 別のコンテキストでtryを呼び出すと、コンパイル時エラーが発生します。

（擬似コード）のように関数呼び出しf（）でtryを呼び出す

x1, x2, … xn = try(f())

turns into the following (in-lined) code:

t1, … tn, te := f()  // t1, … tn, te are local (invisible) temporaries
if te != nil {
        err = te     // assign te to the error result parameter
        return       // return from enclosing function
}
x1, … xn = t1, … tn  // assignment only if there was no error

つまり、「expr」によって生成されたエラー型の最後の値がnilの場合、tryは最初のn個の値を返すだけで、最後のnilエラーは削除されます。 「expr」によって生成された最後の値がnilでない場合、囲んでいる関数のエラー結果変数（上記の擬似コードではerrと呼ばれますが、他の名前が付いているか、名前が付けられていない可能性があります）は、そのnil以外のエラー値に設定されます。囲んでいる関数が戻ります。 囲んでいる関数が他の名前付き結果パラメーターを宣言している場合、それらの結果パラメーターは、それらが持つ値を保持します。 関数が他の名前のない結果パラメーターを宣言する場合、それらは対応するゼロ値を想定します（これは、既に持っている値を保持することと同じです）。

この図のようにtryが複数の割り当てで使用され、nil以外のエラーが検出された場合、（ユーザー定義変数への）割り当ては実行されず、左側の変数はいずれも実行されません。割り当てが変更されます。 つまり、tryは関数呼び出しのように動作します。その結果は、tryが実際の呼び出しサイトに戻った場合にのみ使用できます（囲んでいる関数から戻るのではありません）。 結果として、左側の変数に結果パラメーターという名前が付けられている場合、tryを使用すると、現在見られる一般的なコードとは異なる結果になります。 たとえば、a、b、およびerrがすべて、囲んでいる関数の名前付き結果パラメーターである場合、このコードは

a, b, err = f()
if err != nil {
        return
}

f（）がエラーを返したかどうかに関係なく、常にa、b、およびerrを設定します。 対照的に

a, b = try(f())

エラーが発生した場合、aとbは変更されません。 これは微妙な違いですが、このようなケースはまれであると考えています。 現在の動作が予想される場合は、ifステートメントを保持します。

これらは、tryの説明にあるテキスト全体がstrings.HasPrefixに存在しないという点で異なります。 より良い質問は、どのように似ているかということです。私は、どちらも通話のいくつかの側面を共有し、他には何も共有していないと答えます。

私は以前に、チェックという名前の「制限された」試行を受け入れ、ネストを禁止することを読みました。

tryに対する私の中心的な議論を読んでくれてうれしいです：実装は十分に制限的ではありません。 どちらの実装も、簡潔で読みやすいすべての提案の使用例と一致する必要があると思います。

提案には、実装に一致する例を含める必要があります。これにより、提案を検討しているすべての人が、Goコードに必然的に現れるものにさらされる可能性があります。 どの言語/環境でも発生する、理想的に記述されていないソフトウェアのトラブルシューティング時に直面する可能性のあるすべてのコーナーケースに加えて。 複数のネストレベルでスタックトレースがどのように見えるかなどの質問に答える必要があります。エラーの場所は簡単に認識できますか？ メソッド値、無名関数リテラルはどうですか？ fn（）の呼び出しを含む行が失敗した場合、以下はどのタイプのスタックトレースを生成しますか？

fn := func(n int) (int, error) { ... }
return try(func() (int, error) { 
    mu.Lock()
    defer mu.Unlock()
    return try(try(fn(111111)) + try(fn(101010)) + try(func() (int, error) {
       // yea...
    })(2))
}(try(fn(1)))

合理的なコードがたくさん書かれることはよく知っていますが、今ではこれまで存在しなかったツール、つまり明確な制御フローなしでコードを書く可能性のあるツールを提供しています。 ですから、そもそもなぜそれを許可するのかを正当化したいと思います。この種のコードのデバッグに時間を無駄にしたくはありません。 私はそうすることを知っているので、あなたが彼らを許せば誰かがそれをするだろうという経験が私に教えてくれました。 その誰かはしばしば知らされていない私です。

Goは、他の開発者と私が同じありふれた構造を使用するように制限することで、お互いの時間を無駄にするための最小限の方法を提供します。 圧倒的な恩恵なしにそれを失いたくありません。 「tryは関数として実装されているので」が圧倒的なメリットになるとは思いません。 その理由を教えてください。

このエラー処理の問題に時間を無駄にしないでください。ジェネリックスを提供してください。Rustの結果のようなものを作成します。

Goは立ち往生していて、魔法の、または単純なアイデアのための論理の間で苦労しています。

長所：

• ボイラープレートを減らす
• 単純
• 他の言語の中でも既存のパターン
• オプション

短所：

• 学習曲線
• 根底にある魔法
• 新しい種類のバグ
• Goは意見があり、 if != nil実用的ですが、 try使用することもできます。

私はこのコミュニティ、特にのように感じます。 ここでは、Go Survey [1]で投票された人々とは異なります。
有権者はこれを主な関心事として選択せず、将来の検討に任せるかもしれません。
しかし、その配置のために影響があると見なされました。

IMO、言語機能の追加は古く、最新のプログラミング方法では、エディターに機能を追加しています。つまり、エメットまたは言語スニペット、コードの折りたたみと色付け、リファクタリングとフォーマット、デバッグとテスト、エラーの解決策の提案、godocまたはスタックオーバーフローからの引用です。 、ソースコードの上にUIを置き、ソースコードを冗長のままにします
コードはif err != nilをtry折りたたむ

私は、エラーの処理を忘れることなく、より厳密なエラー処理に投票した人でした。 試してはいけません。

RustのResultタイプのようにリモートで何かをリメイクするには、ジェネリックよりもはるかに多くのものが必要になります。 Result型をジェネリックのみで作成できる場合でも、初心者プログラマーは、エラーを適切に処理する前にジェネリックを知っているか、関数「 Result方法でエラーを返す」必要があります。 「」

@deanveloper 、私のポイントは次のとおりです。「構文の変更」よりもジェネリックの恩恵を受けることがたくさんあり、それはコミュニティにも当てはまると思います。

@txgruppiジェネリックスの優先度を高くする必要があることに同意できます。 私は、ジェネリックがエラー処理の良い代替になるとは思わないと言っていました。

@deanveloper 、私の意見では、このエラー処理の問題は単なる見た目です。人々は、いくつかの追加コードを入力する必要があるという理由だけで、安定していてうまく機能するものについて議論することに時間を費やしています。 より良いコードを書く方法を学び、設計変更でこれを解決するだけです。
誰かがジェネリックスを言う前に、より良いコードで修正するのは同じくらい簡単です：コンパイル時エラー...

スニペットまたはキーボードマクロで解決できますか？ その後、それは問題ではありません。

@txgruppi

より良いコードを書く方法を学び、設計変更でこれを解決するだけです。

Robert Griesemerが彼のtryhardツールを使用して見つけたように、標準ライブラリ内のすべてのエラー処理コードの70％は、現在try適しています。 （まだ存在していない） fmt.HandleErrorf関数を使用するなど、コードを変更すると、さらに多くの対象になります。 標準ライブラリを悪いコードと呼びたくないと思います。

スニペットまたはキーボードマクロで解決できますか？ その後、それは問題ではありません。

また、コードを読むことでもあります。 だから私たちはthing.Thing thing = new thing.Thing(thing.THING);好きではありません

@ faiface 、 'if err！= nil'は、高品質のソフトウェアの開発に
ジェネリック医薬品の不足は、高品質のソフトウェアの開発の途上にありますか？ はい、そうです。

私の見方では、ジェネリックを実装するのに十分な知識がないので、誰かがそれを実装する必要がありますが、このエラー処理は、ジェネリックを実現できる心にとっては時間の無駄です。 私はこのエラー処理に反対していません。それは悪いことだからです。解決すべきもっと重要なことがあるので反対です。

@faiface標準ライブラリは、実際のGoコードを適切に表現したものではありません。 これは、標準ライブラリがコンテキストを追加せずにエラーを単純に渡す可能性がはるかに高いためです。たとえば、 io/ioutilは実際にエラーを装飾する必要ioで発生したエラーを単純に渡すことができます。

@deanveloper @faiface Go Corpusに対して実行された場合：

--- stats ---
 401679 (100.0% of  401679) func declarations
  97496 ( 24.3% of  401679) func declarations returning an error
 991348 (100.0% of  991348) statements
 217490 ( 21.9% of  991348) if statements
  88891 ( 40.9% of  217490) if <err> != nil statements
    485 (  0.5% of   88891) <err> name is different from "err" (-l flag lists details)
  59500 ( 66.9% of   88891) return ..., <err> blocks in if <err> != nil statements
  29391 ( 33.1% of   88891) complex error handler in if <err> != nil statements; cannot use try (-l flag lists details)
    596 (  0.7% of   88891) non-empty else blocks in if <err> != nil statements; cannot use try (-l flag lists details)
  52810 ( 59.4% of   88891) try candidates (-l flag lists details)

したがって、実際のコードでは、ifステートメントの40％がエラーチェック用に記述されており、 try使用すると、それらの59％をそのまま使用できます。

同意します。 err！= nilの場合は問題ありません。 単一のエラー値を返す関数にとっては、シンプルでクリーンです。 また、エラーのコンテキストが重要な場合のエラーパッケージとその原因/ラップ関数も気に入っています。 コードプロパティでカスタムエラーを使用するには（私が知る限り）、型アサーションを実行するか、標準エラーインターフェイスの代わりに何かを使用する必要があります。 いずれにせよ、私はGoコードを読んだり書いたりして、エラー処理が現在どのように機能しているかになんらかの不快感を感じたことはありません。 私が遭遇した煩わしさは、アイテムのコレクションを処理した結果として複数のエラーが発生する可能性がある場合です。 ただし、これは設計上の問題であり、言語の問題ではありません。

「エラーのコンテキストが重要な場合」と言うときは、ネットワークの一時的な中断が発生したために再試行したい場合、または「検索」タイプの呼び出しの結果が発生したために結果が返されない場合を指していることに注意してください。実際には何もありません。または、私のひねくれた指がSQLクエリにランダムな「s」を追加して爆発させています（これは私に頻繁に起こります...おそらく神経損傷をチェックする必要があります）。

7/5/19に、NicolasGrillyの[email protected]は次のように書いています。

@kroppt私は何十回も読んだ;-)私は試してみるという考えに同意しません
コードを難読化する。 tryは、いくつかを因数分解するために使用される組み込み関数です。
反復コード。 私たちはプログラマーとして常にそれを行っています。 私たちが特定するとき
繰り返しパターン、新しい関数でそれを除外します。 そうしなかった場合、
すべてのコードがインライン化された1つの長いmain（）関数があります。

私はあなたを不誠実と呼びたくなりますが、私はイアン・ランス・テイラーの
議論を丁寧に保つための超人的な努力と私は本当にできません
このフォーラムに意図的に嘘をつくことで誰もが何を得るかを見てください。

とはいえ、「繰り返しパターンを特定するときは、それを考慮に入れます。
新しい関数。」確かに、しかし矛盾する構造を提供することによってではありません
それは、囲碁の開発のこの後期段階では、2つで長くなります
隠された機能：1つ目は、「
引数リストは、特別な（または他のすべてのものとして） error値で終わります。
セマンティックエラーとして）そして2番目は隠された制御フローを提供します
「リターン」と類似しているが完全に同一ではない迂回路
声明。

「延期」を使用すると対処するために導入される燃えるようなフープを気にしないでください
「try-疑似関数」のより難解な使用法で。 誰か
他の場所では、大まかに「コードでtryに出くわしたくない
私は読んだ」。私は同じように感じます、そしてそれは下に流されるべきではありません
カーペット。

私は、「エラーリターン」の「リターン」の側面であると述べました。
対処する必要があり、「エラー時」の提案が最も近くなります
その原則だけでなく、ルールをいくらか曲げます。 私自身もそうです
「失敗」の提案（最後の引数を最初の引数に移動します、それは
私を不幸にする）。

さらに深く言えば、SNOBOLを除いて、どの言語もありません。
私が精通していることは、ロブ・パイクが説明した飛躍を遂げました
Goが持っている程度の「エラーは価値」ですが、何かが失われました
プロセス中：エラー「条件」は値ではありません。 成功
関数の完了は特殊なケースであり、それぞれが可能です。
失敗。

それぞれ（そしてそれは正常な完了に適用されます。
複数の場合も）そのメリットを考慮して扱う必要がありますが、
呼び出された関数は、に関する意見を私たちに伝えなければならないと主張します
省略形での完成の質、
永遠に行われ、ロブは誤解であることが示されています。

ポイントを説明するために、リーダーからの戻り値を検討してください。
io.EOFは特殊なケースであり、成功することもあれば、成功することもあります。
失敗しますが、Go標準では、誇らしげにエラーです（ "io.Err！= nil"）。
それを短縮する方法もありますか？ ほぼ確実に
そうではありません。なぜなら、私たちはその「間違い」を「許す」ことにかなり慣れているからです。

ループ出口が同様の「ステータス」を伝えるのを長い間待っていました。
条件コード（検索は、見つかった値または失敗で終了する場合がありますが、どのように
別のことをしたいのなら、どちらを教えますか？ テストを追加し、
知識がすでに存在する場所-同じ問題、異なる
環境）。

これらは、従来の言語に対する実際の拡張機能です。ボイラーの削減
比較すると、プレートはばかげています。

そして、三項演算子との比較も同様に有効です：if ？：
「乱用されないように」許可されていない場合は、試行を許可してはなりません。
少なくともそれらの理由で。

率直に言って、試してみてください。 それはGoを間違ったことに対してより魅力的にします
観客。 それをすることの危険のほかに-誰が間違った人々を望んでいるのか
私たちのコミュニティに参加するには？ -先例の問題と問題があります
意図せざる結果の。 私は「それをスクラップする」と言い、それを受け入れましょう
下位互換性が可能なポイントにはまだ到達していません
無視されるので、エラー処理は冗長なままでなければなりません。

パニック/回復があり、三流から昇格する必要があります
すべての説明とともに、それができる自発的なヘルパーへの市民
それは初心者（そして私、私はそれを怖がっていることを認めます）をもっと作ります
自信を持って使用できます。

エラー処理内の「defer」構造（私が採用したもの-
他の場所でのインポートを実現せずに-一貫してファイナライズ
SQLトランザクション：tx.Rollback / tx.Commit）は私にとって啓示でした。
の範囲内で学ぶことができるより多くの原則があるかもしれません
Goがすでに提供しているもの：今はそのボックス内にとどまりましょう。

そのようなことの1つは、カフから外れて、エラー報告に渡すことです。
従来の方法で実行される「error.Methods」のリストを機能させる
結果を報告する代わりに、条件（io.EOF、sql.ErrNoRows）
白黒として。 しかし、私はそのような問題で学校に通っていません、私の提案
ナイーブすぎるので、他の人（ロジャー、聞いていますか？）に同じように育てさせてください
実現へのアイデア。

ルシオ。

「タイプするのは面倒ではありません。同じものがある場合、読むのは面倒です。
どこでも3行。 それは繰り返しであり、私たちプログラマーは通常
これらを除外する傾向があります。 たぶん試してみると他の欠点がありますが、これはそうではありません
私が思うに。」

繰り返しますが、不誠実または少なくとも合理化。 私はそれらを認めます
3行は、書き込まれるよりも何度も読み取られますが、
緩和することを目的としたGriesemerの痛みは、読書ではなく執筆にあります

• それは間違いなく彼が有益な結果として認識している。

しかし、「err！= nil」は非常によく知られているマーカーであり、「読み取る」場合は次のようになります。
エディターを使用して「検索」するのとは対照的に、そのパターンはどちらも簡単です。
スポットで簡単にキャンセルできます。 それを因数分解することは同じではありません
リーグ。 そして、価格は間違っています。

「私たちプログラマー」は、最初にもっと複雑なパターンを除外する傾向があります。
まれにしか発生しない場合でも。 また、「if err！= nil {return
err} "は、非常に単純な一連の命令にコンパイルされます。
誰もしません、ここで手を挙げさせてください。 1つは等しくすることができます
それが「try--thefunction」で起こると確信していますか？

ルシオ。

@lootchやあ、人を不誠実と呼ぶのは本当に非生産的です。あなたがそのようにマークしたステートメントはかなり合理的であるため、彼らはそうではないと確信しています。

私たちはプログラマーとして繰り返しパターンを除外します、それは絶対に真実です。

繰り返しの多いコードは読み取りを遅くするので、それがどのように不誠実であるかもわかりません。

これらに対するあなたの反論は基本的に「人に来なさい、それはそれほど大したことではない」です。 まあ、多くの人にとってはそうです。

間違った人々が私たちのコミュニティに参加することを誰が望んでいますか？

これは超傲慢なゲートキーピングです。 また、 tryhardツールは、 tryが今日のGoコードベースの多くに直接適用できることを明らかにしました。 これは、標準ライブラリのエラー処理コードの70％に直接適用できます。 コードの変更（ deferを使用したエラー装飾の使用など）により、すべてのGoコードのエラー処理の80％以上に適用できると思います。

同意しました、私はここでマークを踏み越えています。 謝罪します。

この議論のように私たちの何人かは首輪の下で熱くなっていると思います
輪になって回っています。

7/7/19で、ミハルŠtrbaの[email protected]は書きました：

@lootchやあ、人を不誠実と呼ぶのは本当に非生産的だ、私は
あなたがそのようにマークしたステートメントがきれいであるようにそれらがそうではないことをかなり確信しています
適正。

私たちはプログラマーとして繰り返しパターンを除外します、それは絶対です
NS。

繰り返しの多いコードは読み取りを遅くするので、それがどのようになっているのかわかりません
どちらか不誠実。

これらに対するあなたの反論は基本的に「人に来なさい、それはそのようなものではありません
大したこと」。まあ、多くの人にとってはそうです。

間違った人々が私たちのコミュニティに参加することを誰が望んでいますか？

これは超傲慢なゲートキーピングです。 また、 tryhardツールはそれを明らかにしました
tryは、今日のGoコードベースの多くに直接適用できます。 それはすることができます
標準ライブラリのエラー処理コードの70％に直接適用されます。 と
コードの変更（ deferなどを使用したエラー装飾を使用するため）、私は信じています
これは、すべてのGoコードのエラー処理の80％以上に適用できます。

-
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください。
https://github.com/golang/go/issues/32825#issuecomment -508971768

-
ルシオデレ
2 Piet Retief St
ケステル（東部自由州）
9860南アフリカ

Ph。：+27 58 653 1433
セル：+27 83 251 5824
FAX：+27 58 653 1435

@lootch自己意識の小道具！ 議論が輪になって行くのを見ることの欲求不満を理解することができます。

私も同じように見て、反対側にいます。

おそらく、双方はお互いを理解できていないだけです。 「try」の使い方という私のブログ投稿を読んだことがあります

7/7/19で、ミハルŠtrbaの[email protected]は書きました：

[...]
おそらく、双方が反対側を理解できていないだけです。 ありますか
How touseという私のブログ投稿を読んでください'試す'？ 私がしようとするところ
'try'の使用が実際にどのように見えるかを示し、滞在するために最善を尽くします
偏りがない？

私はしなかったことを告白します、私は私が決してする必要がないことを熱心に望んでいます:-)

ストックトンが提起したと思う側面を検討しましたか？
トライの利点が表示され、彼は柔らかい下腹を求めます
明らかにされますか？ 私は彼に同意するのではないかと恐れています。
あなたのブログが同じ欠点に苦しむかもしれないこと。

そうでない場合は、私に教えてください、良い読み物には特別な場所があります
私の人生で:-)

ルシオ。

@lootch私は、「try」のできるだけ多くの側面を（つまり、適用される場合と適用されない場合の両方で）短いコードで表示し、

これは、関連するRedditディスカッションで最も賛成されたコメントでした：

これは、偏りのない架空の有用な例です。 会話に建設的なものを追加してくれてありがとう。それは単に「ひどい」だけではありません。

@lootch私は、「try」のできるだけ多くの側面を（つまり、適用される場合と適用されない場合の両方で）短いコードで表示し、

これは、関連するRedditディスカッションで最も賛成されたコメントでした：

これは、偏りのない架空の有用な例です。 会話に建設的なものを追加してくれてありがとう。それは単に「ひどい」だけではありません。

引数としてファイルパスを持つ関数？ これだけで、このコードが私のレビューに合格しない理由になります。 一部のフィールドが欠落している場合はどうなりますか？ 再注文しましたか？

@sirkonもちろん、長すぎないように、例は単純化されています。 発生した問題を修正するために必要となる変更は、エラー処理の慣行には影響しませんが、そこで重要なのはそれだけです。

発生した問題を修正するために必要となる変更は、エラー処理の方法には影響しません。

あなたがそう言ったので？

1. ブログのタイトルから始めましょう。繰り返しますが、ファイルパスをパラメーターとして使用することは非常に悪い習慣であり、率直に言って、以下のコード全体も同様であるため、「書き方」と呼ぶ必要があります。
2. あなたはこれに気づいていますか
   go resp := Respondent{ Name: name, Gender: try(parseField(s, &line, "gender")), OS: try(parseField(s, &line, "os")), Lang: try(parseField(s, &line, "lang")), }
   貧弱なエラーメッセージを生成しますか？ 少なくとも、予期しないフィールドエラーメッセージと欠落フィールドエラーメッセージがあるはずです。 スクリプトの診断は標準以下です。

PSあなたのリポジトリを見てみました。 Goがあなたのタスクにとって悪いツールであることを知っていますか？ 実際のGoのアプリケーションプラクティスでは、ログが最初に表示されるのは開発者ではなく運用エンジニアであることを理解する必要があります。 適切なエラーメッセージは、問題を自分で解決するのに役立つ場合があります。

@sirkonさあ、

これによりエラーメッセージが不十分になることをご存知ですか？

それらはモデルに完全に適切です。 フォーマットには、すべてのフィールドが順番に含まれている必要があります。 エラーメッセージはそれを非常に明確に伝えます。

コードの品質に異議を唱えたいのなら、あなたはそれをあなたの品質基準に書き直してみませんか？ その場合は、 tryを使用するようにコードを書き直すように最善を尽くします。

PSあなたのリポジトリを見てみました。 Goがあなたのタスクにとって悪いツールであることを知っていますか？

私の仕事のために別のものを提案しますか？ 私はかなりの数を使用しました。 ところで、これはかなりオフトピックです。

@faiface

私の仕事のために別のものを提案しますか？ 私はかなりの数を使用しました。 ところで、これはかなりオフトピックです。

さび？ C ++？

@sirkon

さび？ C ++？

そこに行きます。 Goで解決する前に、両方を使用しました。 私は振り返ったことがありません。

@sirkon tryの大きな欠陥の1つは、エラー装飾を思いとどまらせることです。 この場合のプログラマーはtry可能なアプリケーションを示していたので、もちろんエラー装飾はあまり行われていません。

また、彼らが取り組んだプロジェクトに基づいて人々の信用を傷つけることは完全にトピックから外れており、求められていません。 あなたは過去のいくつかのコメントでかなり失礼でした、そして私はあなたに少なくともそれを知ってもらいたいです。

@deanveloperコメントありがとうございます！

ところで

この場合のプログラマーは、tryの可能なアプリケーションを示していたので、もちろん、エラー装飾はあまり行われていません。

私のブログを参照している場合、実際にはかなり多くのエラー装飾が行われていますが、 @ sirkonとまったく同じ方法ではありません。 tryを使用するプログラムからのエラーメッセージは次のとおりです。

parse respondnts.txt: open respondnts.txt: no such file or directory
parse respondents.txt: line 12: parse field gender: expected "gender:"
parse respondents.txt: line 9: expected empty line
parse respondents.txt: line 4: parse field lang: EOF

@faiface私の間違い、もっと具体的にすべきだった。 tryは、同じ関数内に複数のエラーメッセージが必要な場合のエラー装飾を推奨しません。 check/handleドラフトと「名前付きハンドラー」の反対提案でこれを行うことが可能tryを使用していた）で各メッセージの周りに装飾を追加できると非常に便利

ただし、特定のケースでは、チェック/処理はそれほど役に立ちませんでした。 しかし、 catchおよびtryに対する他の反対提案の提案されたアイデアは、追加の装飾を追加するようにエラーを処理することができたでしょう。

@deanveloperさて、サブ関数は独自のコンテキストを提供することが期待されるため、ほとんどの場合、関数内のすべてのエラーに同じ装飾を使用する必要があります。 ただし、1つの関数で異なる装飾を行う必要がある場合でも、tryを使用すると簡単な解決策があります。

..., err := functionThatCanFail(...)
try(errors.Wrapf(err, ...))

または、大きな関数を複数の小さな関数に分割するだけです。

その時点で私の目で@faifaceは1だけで使用する必要がありますif err != nil 、私はそれは好みの問題だと思います。

ただし、場合によっては（struct-initializingの場合のように）、複数の関数に分割することはお勧めできません。 私は推測しますが、私は少し気まぐれになっています。

私は実際にはtryに反対しているわけではありませんが、私もそれほど大きな支持者ではありません。 私はそこに別のより良い解決策があると思います。

@deanveloper

ただし、場合によっては（struct-initializingの場合のように）、複数の関数に分割することはお勧めできません。

本当ですが、必要な特定の装飾はすべてparseFieldからのものであるため、それらを異なる方法で装飾する必要もありません。

私はそこに別のより良い解決策があると思います。

それはかなり可能です！ より良い解決策が見つかったら、1分でtryをドロップします:)

ほとんどの場合、サブ関数は独自のコンテキストを提供することが期待されるため、関数内のすべてのエラーに同じ装飾を使用する必要があります。

@faiface私はこの声明に強く反対します。 すべての関数は、呼び出しスタック上の別の関数のサブ関数です。 これは、エラー処理フローで同じ責任があることを意味します（つまり、上位スコープにエラーコンテキストを提供します）。

2つのデータチャンクを1つのファイルに追加する関数を想像してみてください。 'could not write to file'ステートメントをかろうじて返す場合、これらの追加のどれが失敗したかをどのように区別しますか？

私たちは皆怠惰な生き物です。 私もできれば一度だけ何かをしたいです。 はい、Goで冒険を始めたとき、エラー処理は少し面倒だと思いました。 数年後、私の視界は180度になりましたが練習しました。 Goでの現在のエラー処理は、責任あるプログラミングと優れた設計を促進すると思います。 私見では、このアプローチを弱体化させる別のメカニズムを追加することは大きな失敗です。

@mklimuk私のコメントの重要な部分は、「ほとんどの場合」です。 あなたが提供した例は、おそらくif err != nilによって最もよく処理されます。 何度も指摘されているように、 tryはすべての状況を処理するように設計されているわけではなく、最も一般的な状況だけを処理するように設計されています。

標準ライブラリのすべてのエラー処理コードの70％がすぐに使用できるtryあり、同じことがすべてのエラー処理コードの59％にも当てはまるため、証拠はそれがそうすることを示しています。野生。

@faifaceは、 tryが明示的なエラー処理を置き換えることができるという事実は、そうすべきであるという意味ではありません。 私の場合、コンテキストを追加せずにエラーを返すことは「最も一般的な状況」ではありません。 それは反対です:)

このスレッドに賛成する人々は、この新しいステートメントが、Goコードの冗長性を減らすために、元のGoデザインの背後にあるすべての努力（単純さ、明快さなど）を台無しにすることを懸念しています。

もちろんですが、 tryはコンテキストなしでエラーを返すためのものではないことを理解してください。 実際、コンテキストを追加する最も一般的なケース（関数ごとに1つのコンテキスト）は、 tryによって大幅に簡略化されています。

func doSomething() (err error) {
    defer fmt.HandleErrorf(&err, "doing something")

    x := try(oneThing())
    try(anotherThing(x))
    // ...
}

ほとんどの場合、 oneThing()とanotherThing()はそれ自体で十分なコンテキストを返すため、単純な"doing something: ..."ラップするだけで十分です。

ちなみに、装飾を行う人にはいくつかの規則を使用できると思います。 stdlibでは、 copy: x to yなどの一部の関数がこれを実行します。引数があるため、私は個人的に装飾を呼び出し元に任せています。

たとえば、 Copy()がある場合、 return errors.Wrap(err, "writing")ようなことを行い、 Copy()を使用する発信者はerrors.Wrapf(err, "copying from %v to %v", src, dst)などでラップします。

これら2つはうまく混ざり合わず、文字列が重複することがありますが、stdlibスタイルは慣用的であると言うのが最善ですか？ しかし、私はそれらすべてがこのように振る舞ったことを覚えていません。 @faifaceの例で十分だと思うのはそれだけだと思います。 たぶん私は問題を逆転させてきましたが、私にとっては、特に「万が一に備えて」コンテキスト情報を省略した場合に備えて、より少ないことを行い、決定を発信者に任せる方がクリーンだと感じています。

議論があるので、私は個人的に装飾を発信者に任せてきました。

はい。 たとえば、HTTPリクエストからJSON本文を解析し、ヘッダーなどをチェックする関数について考えてみます。 構文的に無効なJSONが提供された場合、その責任は、実際にできることはすべて、エラーを報告することです。 _caller_は、APIのどの部分が呼び出されようとしていたかを認識しており、チェーンに渡すかHTTPエラーを発行する前に、それに応じてエラーを装飾する必要があります。

関数が複数の場所で使用される可能性のある汎用コードを本当に除外している場合、エラーを装飾するために必要な情報が関数に含まれていません。 逆に、それらがすべてのコンテキストを持っている場合、それらはおそらくスタンドアロン関数として意味のある関数ではなく、コードを分割して実際よりも整理されたように見せるための関数を作成しているだけです。

@lparこれの具体例を挙げてください。

私はすでに具体的な例を挙げましたか？ parseJSON関数が実際にコンテキストを認識していて、本体を解析するAPIエンドポイントとアクティビティフローを装飾できたかどうかを検討してください。 これは、そのエンドポイントに固有であるか、エラーをラップするために使用できるように情報を渡していたことを示しています。

@lparわかりました。これは、 if err != nilが引き続き使用されるもう1つの例です。 または、ロジックを複数の関数に分割します。

ただし、 tryが適切でない例を示すことは、 tryに対する議論ではないことを理解してください。 tryは、すべてのエラー処理を置き換えることを意図したものではなく、最も一般的なケースだけを置き換えるものです。

@ abejide001 try提案は、他の多くの言語の従来の「try / catch」ではなく、Rustのtry!マクロによく似ています。 いいミームなのに笑

おっと-間違った問題に投稿されました。 https://github.com/golang/go/issues/32437#issuecomment-509024693に移動しました。

私は最近、 tryマクロが持つ危険なネスト機能との意見の相違に基づいた＃32968の提案を投稿しました。 重大な欠陥がないことを願っていますが、著者として私はそれを見るのにふさわしい人物ではありません。 ですから、キャンプを_試さないでください_（あなた:)に見て、評価して、コメントしてもらいたいと思います。

抜粋：

• _ checkマクロはワンライナーではありません：それは多くの反復的な場所で最も役立ちます
  同じ式を使用したチェックは、近接して実行する必要があります。_
• _その暗黙のバージョンはすでに遊び場でています。_

設計上の制約（適合）

これは組み込みであり、1行にネストせず、 tryよりもはるかに多くのフローを可能にし、内部のコードの形状については予期していません。 それは裸のリターンを奨励しません。

使用例

// built-in 'check' macro signature: 
func check(Condition bool) {}

check(err != nil) // explicit catch: label.
{
    ucred, err := getUserCredentials(user)
    remote, err := connectToApi(remoteUri)
    err, session, usertoken := remote.Auth(user, ucred)
    udata, err := session.getCalendar(usertoken)

  catch:               // sad path
    ucred.Clear()      // cleanup passwords
    remote.Close()     // do not leak sockets
    return nil, 0, err // dress before leaving
}
// happy path

// implicit catch: label is above last statement
check(x < 4) 
  {
    x, y = transformA(x, z)
    y, z = transformB(x, y)
    x, y = transformC(y, z)
    break // if x was < 4 after any of above
  }

これがお役に立てば幸いです、お楽しみください！

ただし、 tryが適切でない例を示すことは、 tryに対する議論ではないことを理解してください。 tryは、すべてのエラー処理を置き換えることを意図したものではなく、最も一般的なケースだけを置き換えるものです。

そして、私が以前に投稿した統計によると、それらは私のコードで最も一般的なケースではありません。 私のコードで最も一般的なケースは、戻る前にラップされたエラーです。 したがって、 tryは、エラーが返される1桁の割合（*）にのみ適切であるため、より良いものが必要だと思います。

（*）実際、裸のerrリターンインスタンスは、修正する必要のあるエラーである可能性が高いと思う傾向があります。

完全に同意します。「iferr！= nil」はそのままにしておきます。

@ abejide001 try提案は、他の多くの言語の従来の「try / catch」ではなく、Rustのtry!マクロによく似ています。 いいミームなのに笑

これだけが私にとっての懸念事項です。Goはすでに新参者にとって奇妙な言語です。そして今、 tryが特注のロジックを持っている理由を説明する必要があります。 FWIW、「Rust did it」と言っても、言語に何かを追加することを正当化する正当な理由ではないと思います。それはあまり知られていないだけです。

@機能を正当化するために言っているのではなく、機能が何をしたのかを明確にするために言っているだけです。 私はtry提案の真っ最中です。

これが大きな違いを生むわけではありませんが、マクロの代わりにキーワードを使用する場合でも、Swiftの機能でもあります。

正確に何を達成しようとしているのかについては、多少の混乱があるようです。 私見、問題はエラーをチェックする複数のifブロックを書き込んでいないことです。 あなたはそれらを一度書けば完了です。 問題は、これらのブロックが複数あるコードを読み取ることです。 私たちは書くよりも読むことをたくさんします。 そして、これらのブロックは実際のコードと絡み合っているため、実際のコードを難読化します。 さらに悪いことに、多くの場合、それらはほぼまったく同じであり、ifブロック内のどこかにわずかな文字列の違いしかありません。

私は個人的に古いチェックを好みました-ドラフトを処理しますが、これは少なくともエラーとビジネスパスを分離するのに良い仕事をします。 そして、現在、親エラーと同じことを繰り返す可能性が高い各呼び出しとは対照的に、最終的に単一の関数スコープコンテキストを持つことができる可能性があります。

@icholyは書いた：

より合理化されたエラー処理を要求する圧倒的なコミュニティフィードバックがありました（年次調査から）。 Goチームは現在その問題に取り組んでいます。

ここで調査を調べました： https ：

どうやら質問は、「今日Goを使用して個人的に直面する最大の課題は何ですか？」でした。 考えられる答えは「エラー処理」です。

その質問と回答に基づいて、より簡単な構文が必要であるとどのように推測されたのか、真剣に疑問に思います。 「エラー処理」にも答えたかもしれませんが、決して別の構文を見たかったわけではありません。 調査でこのオプションをチェックした場合、エラーをラップしたり、スタックトレースを提供したりすることを許可したほうがよいと思いました。

私の提案は、すべてのエラー処理の提案（事実上、 @ miekgが提案していたもの）から

私はtryの提案を行ったばかりですが、何かが足りない場合を除いて、「定型文のifステートメントを削除する[...}」以外に、提案されている理由を言うのを怠っています。 しかし、ステートメントが必要な場合にこれらの定型文を削除する理由については言及されていません。

私は間違いなく上記に同意します。 新しいエラー値の変更が、Goに関するエラー処理の苦情に役立つかどうかを見てみましょう。 次に、より簡単な構文が必要かどうかを確認できます。

ここの人々は、返されたすべてのエラーに注釈を付ける必要があると感じているため、 try反対しています。 現実には、現在のコードコーパス（標準ライブラリを含む）では、エラーチェックの割合が高く、注釈なしのエラーが返され、 try恩恵を受けます。 コードがどうあるべきかのあなたの信念は、コードが道とは何の関係もありません。 私にあなたの教義を惜しまないでください。

@icholyエラーを無視することは、

私の提案は、すべてのエラー処理の提案（事実上、 @ miekgが提案していたもの）から

私はこれに強く同意します。 Goエラー処理の改善がどの機能をサポートすべきかについて、多くの基本的な意見の相違が見られます。 人々が言及する機能のさまざまなチャンクはすべて、その名前と構文をめぐってバイクシェッドを引き起こしているため、議論はどこにも行きません。

提案されている新しいエラー処理機能に対して、より広範なGoコミュニティが実際に何を望んでいるのかを詳しく知りたいと思います。

さまざまな機能、人々が提案しているエラー処理機能の一部をリストした調査をまとめました。 私は提案された名前や構文を注意深く_省略_しました。もちろん、私自身の意見を支持するのではなく、調査を中立にしようとしました。

参加を希望する場合は、共有用に短縮されたリンクを次に示します。

https://forms.gle/gaCBgxKRE4RMCz7c7

参加するすべての人が要約結果を見ることができるはずです。 そうすれば、人々が実際に何を望んでいるのかがよくわかったら、tryの提案がそれらを提供するかどうかについてインテリジェントな議論を行うことができるでしょう。 （そして、構文についての議論に進むかもしれません。）

@ lane-c-wagner注釈なしのエラーを返すことは、まったく返さないことと同じだと言っているのですか？ 編集：前のコメントを修正

@icholyああ私は誤解しました。 あなたが「裸」と言ったとき、私はあなたが「_」がエラーを無視したことを意味していると思いました。

この提案は、いかなる行動も有効な行動であってはならないと主張しています。 この変更は、コードを読むため、言語のすべてのユーザーに影響します。 そのため、最大のハードルを特定する調査では、このハードルを修正する価値があるかどうかをコミュニティに尋ねる必要があります。 この提案は、そのような質問の最も近い評価です。

「誰もが自由に無視できる」と言うのはやめてくださいtry 。 他の人が書いたコードを読みます。

@ tv42あなたがここで私に話しかけて

あなたが調査した@griesemerは非常に不足していました。 私はエラー処理に投票しましたが、私が意図した問題は、冗長性ではなく、完全な型の安全性でした。 エラーについてのみ別のものを作成する方がよいでしょう。

そして、私はまだ合計型が必要です。

これは、エラー！= nilの場合にgofmtが現在フォーマットする方法に関する提案です。

（これはtry（）提案についての意見ではありません。）

ifステートメントが次のような1行の非nilエラー値を返す場合。

err := myFunc()
if err != nil {
    return err
}

gofmtは、独自のifステートメントルールを緩和して、次のように1行でフォーマットできます。

err := myFunc()
if err != nil { return err }

3行のエラー処理コードは1行になります。 整理整頓。 プログラムフローを追跡しやすくなります。

これでどこに線を引くか（しゃれを認める）について何らかの判断が必要になります
gofmtルールの変更。 次のような装飾が含まれている場合があります。

err := myFunc()
if err != nil { return fmt.Errorf("myFunc() blew up! %v", err }

ただし、複雑な複数行のエラー処理はそのままにしておく必要があります。複数行で明確かつ明示的です。

_try_プロポーザルは取り下げられました： https ：

ジェネリックは誰ですか？

これは、エラー！= nilの場合にgofmtが現在フォーマットする方法に関する提案です。

私はそれを試しましたが、コードは複数行のフォーマットよりもその方法ではさらに読みにくくなっています。 tryはその解決策よりもはるかに優れています。

ここでのIMOの問題は、エラー処理の実行方法ではなく、無視されるかどうかです。 if err != nil構文をそのままにして、 Error戻り値の無知を制限することはできませんか？ レガシーコードの重大度オプション付きのコンパイラ警告/エラーにするように。

ここでのIMOの問題は、エラー処理の実行方法ではなく、無視されるかどうかです。 if err != nil構文をそのままにして、 Error戻り値の無知を制限することはできませんか？ レガシーコードの重大度オプション付きのコンパイラ警告/エラーにするように。

多くの人は、無視されたエラーを表示するリンターを望んでいます。

これを難しいエラーにしたいと思いますが、すでに書かれている大量のレガシーを見ると、リンターも公平です。

https://github.com/kisielk/errcheckは、未処理のエラーについて教えてくれる価値があると思います@plyhun @sorenvonsarvort

＃32437の議論に見られるように、この提案は今のところ事実上受け入れられています。 閉鎖。 問題が再度発生した場合は、新しい提案を開くことができます。

多くの提案がうまく適合していないと感じる理由の1つは、実際には2つの異なる問題に同時に対処しようとしているためだと思い始めています。 確かに、ほぼすべての関数呼び出しの後にerr != nilブロックがあると、コードの流れが奇妙な方法で分割される可能性がありますが、確かに利点はありますが、それは半分にすぎないと思います。問題。 もう1つの問題は、エラーが発生したかどうかに関係なく、複数の返品を処理するのが非常に不格好になる可能性があることです。

複数のreturn関数は、2つの間のわずかな違いにもかかわらず、単一のreturn関数とは非常に異なった感じがします。 これは、複数の引数を取る関数の呼び出しに追加の制限があった場合のようなものです。 時々対処するのは非常に奇妙に感じます。 複数の戻り値を持つ関数を呼び出す場合、ほとんどの場合、独自の行で呼び出す必要があり、 :=と組み合わせると、他の場所で説明されているさまざまな変数シャドウイングの問題の主な原因となることがよくあります。 。 メソッド呼び出しをそれらにチェーンすることはできません。また、それらから構造体フィールドと同じ行の新しい変数に直接割り当てることもできません。

わからない。 多分それは私だけです。 しかし、私はGoを10年近く使用しており、複数の戻り値を持つ関数を呼び出すことは、私にとっては少し厄介なこともあります。

ありがとうございました！

if err != nilには実際に1つの問題があり、 errのスコープは本来よりも長くifをインライン化すると問題は解決しますが、すべてのケースをインライン化できるわけではありません。

if err := foo(); err != nil {

if _, err := bar(); err != nil {



md5-6a135eb952fe7b24b3389cb16d3244a1



a, err := bar()
if err != nil {



md5-d52f811d3e31bb368bd8045cfb2e93b4



var err error
baz.A, err = bar()
if err != nil {

if err != nil {}ブロックが完了した後は、 err変数が関数スコープに存在しないようにする必要があります。 これは、問題を修正するためのtry()提案から構築された私の提案ですhttps://github.com/golang/go/issues/33161。 建設的なフィードバックが欲しいです。

if err！= nil {}ブロックが完了した後は、err変数を関数スコープに存在させないでください。

ifブロックが完了した後、なぜそれが存在しないはずなのですか？ コンパイラーはそれを最適化でき（必要と思われる場合）、err：= stmt（）\ nif err！= nil {}ブロックが完了すると、これらはほとんど常に一緒になるため、精神的な負荷はありません。

私はまだあなたの提案を詳細に検討していません（ただし、それを書く努力をしたことに対する称賛です！）。 ただし、上記のコメントでも概説したように、問題を解決するための提案を掘り下げる前に、認識された問題についてさらに調査する必要があると思います。

@Freeaqingmeエラーは、 if err != nilブロックが完了した後は存在しないはずです。これは主に、すでに存在しないように動作しているためです。

CopyFileの例では、 r, err := os.Open(src)後にw, err := os.Create(dst)続きます。 2番目のerrは、最初の

他にも奇妙なことがあります。 err := foo()以降にbar.V, err = baz()ようなものがある場合、コードがリファクタリングされてfoo（）が不要になった場合は、 baz前にvar err errorを追加する必要があります。 baz行。 。 関数内の別の場所をリファクタリングしても、そのような他の場所に影響を与えるべきではないと思います。

技術的には

    r, err := os.Open(src)
    if err != nil {
        return ...
    }
    w, err := os.Create(dst)

errの2番目のインスタンスは、最初のインスタンスをシャドウしません。 それらは実際には同じ変数です。 https://golang.org/ref/spec#Short_variable_declarationsで変数の再宣言の説明を参照して

func doSomeThing（）{
r、err：= os.Open（ファイル名）
panic（fmt.Errorf（err、 "ファイルを開けませんでした：％s"、filename））//
ここはパニックです。

}

木、2019年10月10日に11:24でclearcodeの[email protected]は書きました：

組み込み関数を追加できると思います。

主張する（）

例：

func doSomeThing（）エラー{

r, err := os.Open(filename)
assert(err, "failed to open file: %s", filename) // in this step, just return the error

resp、err：= http.Get（someURL）
assert（err、 "リクエストに失敗しました"）

}

およびエラーを返さない別の関数：

func doSomeThing（）{
r、err：= os.Open（ファイル名）
assert（err、 "ファイルを開けませんでした：％s"、filename）//ここでパニックになります。

}

したがって、assert（error、args ... interface {}）は次よりも優れています：if err！= nil; {{
エラーを返す}

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/32825?email_source=notifications&email_token=AGUV7XQ5HO7GL3YP72R7BV3QN2N55A5CNFSM4H4DL33KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AGUV7XS4JMK44QHIIR3RSGTQN2N55ANCNFSM4H4DL33A
。

要点は、現在のエラーで返される実際のエラーを確認したいということです。
現在の行で機能します。

2019年10月11日金曜日午前9時55分[email protected]は次のように書いています。

func doSomeThing（）{
r、err：= os.Open（ファイル名）
panic（fmt.Errorf（err、 "ファイルを開けませんでした：％s"、filename））//ここはパニックです。

}

11:24 clearcodeの木、2019年10月10日には[email protected]
書きました：

組み込み関数を追加できると思います。

主張する（）

例：

func doSomeThing（）エラー{

r, err := os.Open(filename)
assert(err, "failed to open file: %s", filename) // in this step, just return the error

resp、err：= http.Get（someURL）
assert（err、 "リクエストに失敗しました"）

}

およびエラーを返さない別の関数：

func doSomeThing（）{
r、err：= os.Open（ファイル名）
assert（err、 "ファイルを開けませんでした：％s"、filename）//ここでパニックになります。

}

したがって、assert（error、args ... interface {}）は次よりも優れています：if err！= nil; {{
エラーを返す}

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/32825?email_source=notifications&email_token=AGUV7XQ5HO7GL3YP72R7BV3QN2N55A5CNFSM4H4DL33KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AGUV7XS4JMK44QHIIR3RSGTQN2N55ANCNFSM4H4DL33A
。

率直に言って、 try提供する暗黙のリターンは必要ありません。 ジェネリックスがある場合は、代わりにモナド風の動作を使用するソリューションをお勧めします。

type Result<T> interface {
  Expect(err error) T
  OrElse(defaultValue T) T
}

func From<T>(value T, err error) Result<T> { ... }

私にとって、これは現在提案されているビルトインよりもはるかにクリーンですが、返されるメソッド（値、エラー）と結果が急増するため、上記にさらに変更を加える必要があります

RustのOkとErrはとても似ています。
if err != nil {}多分1ビット良いと思います。

@Yanwenjiepyは意図的なもので、私はRustのResultタイプの大ファンです。

Goを習得してから10分も経っていません。 私が見ていたコードで最初に気付いたのは、このコピーが何度も何度も貼り付けられていたことです。

someValue, err := someFunction();
if err != nil {
  panic(err)
}

私は明らかに専門家ではありませんが、このスレッドにたどり着くのに一目見ただけで価値があるかもしれません。

これは、学習用のコードスニペットを見ているためです。 実際のコードは、パニックやクラッシュだけでなく、エラーを処理する必要があります。

本当ですが、エラーはグループ化できます（そして多くの場合そうすべきです）。 そのため、try / catchブロックは他の言語に存在します。 たとえば、次のようなものは、私にとって恐竜のような匂いがはるかに少ないでしょう。

try {
  foo, throw err := someFunction();
  bar, throw err := foo.get();
  baz, throw err := bar.make();
  qux, throw err := baz.transform();
} catch(err) {
  // "Unable to foo bar baz qux."
  tryHarder();
}

もう一度、完全な素人。 しかし、コードは単なるシンボルであり、それらが十分に繰り返される場合は、そのためのシンボルを作成することもできます。 これは非常に頻繁に繰り返される記号のようです。

RobPikeのErrorsAre Valuesの投稿を見て、ヘルパーを使用してエラーをマージし、それらすべてを一度に処理する方法を確認することをお勧めします。 実際には、1つの句ですべての例外をキャッチすることは、実際に何が起こったかについての情報を隠すことになるため、例外を含むほとんどの言語では悪いスタイルと見なされます。 （そして、例を拡張して、キャッチされた個々の例外を分解し、その情報を破棄しない場合、コードはGoと同等である限り終了します。）

リンクをありがとう。 errWriterは完全に無難な解決策です。

本当ですが、エラーはグループ化できます（そして多くの場合そうすべきです）。 そのため、try / catchブロックは他の言語に存在します。 たとえば、次のようなものは、私にとって恐竜のような匂いがはるかに少ないでしょう。

try {
  foo, throw err := someFunction();
  bar, throw err := foo.get();
  baz, throw err := bar.make();
  qux, throw err := baz.transform();
} catch(err) {
  // "Unable to foo bar baz qux."
  tryHarder();
}

もう一度、完全な素人。 しかし、コードは単なるシンボルであり、それらが十分に繰り返される場合は、そのためのシンボルを作成することもできます。 これは非常に頻繁に繰り返される記号のようです。

各関数が重複するエラータイプを返し、すべての関数の結果を適切に処理する必要があるとしましょう。tryHarder（）をどのように記述しますか？

try {
  foo, throw err := someFunction();  // err could be TypeA and TypeB
  bar, throw err := foo.get();       // err could be TypeB and TypeC
  baz, throw err := bar.make();      // err could be TypeA and TypeC
  qux, throw err := baz.transform(); // err could be TypeB and TypeD
} catch(err) {
  tryHarder(); // tell me how to handle each error?
}

以下のコードを理解するのに他の誰かが1分しかかかりません：

foo, err := someFunction();  // err could be TypeA and TypeB
if err != nil {
 // handle err
}

bar, err := foo.get();       // err could be TypeB and TypeC
if err != nil {
  // handle err
}

baz, err := bar.make();      // err could be TypeA and TypeC
if err != nil {
  // handle err
}

qux, err := baz.transform(); // err could be TypeB and TypeD
if err != nil {
  // handle err
}

各関数が重複するエラータイプを返し、すべての関数の結果を適切に処理する必要があるとします。

その例では、あなたは完全に正しいです。