syscall.Chdir(dir) || &PathError{"chdir", dir, e}

eはそこからどこから来るのですか？ 打ち間違え？

またはあなたは意味しました：

func Chdir(dir string) (e error) {
    syscall.Chdir(dir) || &PathError{"chdir", dir, e}
    return nil
}

（つまり、暗黙のerr！= nilチェックは最初に結果パラメーターにエラーを割り当てますか？暗黙の戻りの前にそれを再度変更するために名前を付けることができますか？）

ため息、私自身の例を台無しにした。 現在修正済み： eはerr必要があります。 この提案では、 errをスコープに入れて、代入ステートメントにない場合に関数呼び出しのエラー値を保持します。

アイデアや構文に同意するかどうかはわかりませんが、エラーを返す前に、エラーにコンテキストを追加することに注意を払ったことを認めなければなりません。

これは、 https：//github.com/pkg/errorsを書いた@davecheneyにとって興味深いかもしれません。

このコードで何が起こるか：

if foo, err := thing.Nope() || &PathError{"chdir", dir, err}; err == nil || ignoreError {
}

（ || &PathError{"chdir", dir, e}部分がないと、これが不可能な場合はお詫びします。これは既存の動作の紛らわしいオーバーライドのように感じられ、暗黙のリターンは...卑劣ですか？）

@ object88 ifとforとswitchステートメントで使用されるSimpleStmtでこの新しいケースを許可しなくても大丈夫です。 文法が少し複雑になりますが、おそらくそれが最善でしょう。

しかし、そうしないと、 thing.Nope()がnil以外のエラーを返した場合、呼び出し元の関数は&PathError{"chdir", dir, err} （ errはthing.Nope()の呼び出しによって設定された変数）。 thing.Nope()がnilエラーを返す場合、 ifステートメントの条件でerr == nilが真であることが確実にわかります。したがって、 ifステートメントが実行されます。 ignoreError変数が読み取られることはありません。 ここでは、既存の動作のあいまいさやオーバーライドはありません。 ここで紹介した||の処理は、 ||後の式がブール値ではない場合にのみ受け入れられます。つまり、現在コンパイルされません。

私は暗黙のリターンが卑劣であることに同意します。

ええ、私の例はかなり貧弱です。 ただし、 if 、 for 、またはswitch内での操作を許可しないと、多くの潜在的な混乱が解決されます。

検討の基準は、一般的に言語ではそのままでは難しいことなので、このバリアントが言語でエンコードするのがどれほど難しいかを確認することにしました。 他のものよりもそれほど難しいことではありません： https ：

私は、リターン引数の1つのタイプの値と1つの位置を特別にするというこれらの提案のすべてが本当に嫌いです。 これは、この特定のコンテキストでerrを特別な名前にするため、実際にはさらに悪いものになります。

私は確かに人々（私を含む！）が余分な文脈なしでエラーを返すことに飽き飽きしているべきであることに同意します。

他の戻り値がある場合、

if err != nil {
  return 0, nil, "", Struct{}, wrap(err)
}

それは間違いなく読むのが面倒になる可能性があります。 https://github.com/golang/go/issues/19642#issuecomment-288559297のreturn ..., errに対する@nigeltaoの提案が少し気に入りました

私が正しく理解していれば、構文ツリーを構築するには、パーサーは変数のタイプを知って区別する必要があります

boolean := BoolFunc() || BoolExpr

と

err := FuncReturningError() || Expr

見栄えが良くありません。

少ないほうがいいですね...

戻り値のExpressionListにさらに2つ以上の要素が含まれている場合、どのように機能しますか？

ところで、代わりにpanicIfが欲しいです。

err := doSomeThing()
panicIf(err)

err = doAnotherThing()
panicIf(err)

@ianlancetaylorあなたの提案の例では、 errはまだ明示的に宣言されておらず、「魔法の」（言語が事前定義されている）として引き込まれていますよね？

それとも次のようなものになりますか

func Chdir(dir string) error {
    return (err := syscall.Chdir(dir)) || &PathError{"chdir", dir, err}
}

？

一方（すでに「言語変​​更」としてマークされているため...）
エラー時にショートカットを実行する新しい演算子（!!または??）を導入します！= nil（またはnull許容型？）

func DirCh(dir string) (string, error) {
    return dir, (err := syscall.Chdir(dir)) !! &PathError{"chdir", dir, err}
}

これが遠すぎる場合は申し訳ありません:)

Goでのエラー処理が繰り返される可能性があることに同意します。 繰り返してもかまいませんが、読みやすさに影響を与えるものが多すぎます。 「循環的複雑度」（信じられないかもしれませんが）が複雑度の尺度として制御フローを使用するのには理由があります。 「if」ステートメントは余分なノイズを追加します。

ただし、提案された構文「||」 特に記号は一般にOR演算子として知られているため、読みやすくはありません。 さらに、複数の値とエラーを返す関数をどのように処理しますか？

ここでいくつかのアイデアを投げています。 エラーを出力として使用する代わりに、エラーを入力として使用するのはどうですか？ 例： https ：

すべてのコメントをありがとう。

@opennota良い点です。 それでも機能する可能性はありますが、側面が厄介であることに同意します。

@mattn Return ExpressionListはないと思うので、何を求めているのか

@mattn panicifは、この提案の重要な要素の1つに対応していません。これは、追加のコンテキストでエラーを返す簡単な方法です。 そしてもちろん、今日は簡単にpanicif書くことができます。

@tandrはい、 errは魔法のように定義されていますが、これはかなりひどいことです。 別の可能性は、エラー式がerrorを使用してエラーを参照できるようにすることです。これは、別の方法でひどいものです。

@tandr別の演算子を使用することもできますが、大きな利点はありません。 結果が読みやすくなるわけではないようです。

@henryas提案は、複数の結果を処理する方法を説明していると思います。

@henryas例をありがとう。 この種のアプローチで私が嫌うのは、エラー処理がコードの最も顕著な側面になることです。 エラー処理が存在し、表示されるようにしたいのですが、それが最初に表示されるようにしたくありません。 これは、 if err != nilイディオムとエラー処理コードのインデントにより、今日も当てはまります。エラー処理のために新しい機能が追加されても、それは当てはまるはずです。

再度、感謝します。

@ianlancetaylor私の遊び場のリンクをチェックアウトしたかどうかはわかりませんが、コンテキストを追加できる「panicIf」がありました。

ここでは、やや簡略化されたバージョンを再現します。

func panicIf(err error, transforms ...func(error) error) {
  if err == nil {
    return
  }
  for _, transform := range transforms {
    err = transform(err)
  }
  panic(err)
}

偶然にも、私はGopherConで

func DirCh(dir string) (string, error) {
    dir := syscall.Chdir(dir)        =: err; if err != nil { return "", err }
}

ここで、 =:は構文の新しいビットであり、反対方向に割り当てる:=ミラーです。 もちろん、 =も何かが必要ですが、これは確かに問題があります。 しかし、一般的な考え方は、読者が情報を失うことなく、幸せな道を理解しやすくすることです。

一方、現在のエラー処理方法には、1つの関数で多くのことを実行している可能性があり、一部のリファクタリングが遅れている可能性があることを明確に思い出させるという点で、いくつかのメリットがあります。

ここで@billyhによって提案された構文が本当に好きです

func Chdir(dir string) error {
    e := syscall.Chdir(dir) catch: &PathError{"chdir", dir, e}
    return nil
}

またはhttps://github.com/pkg/errorsを使用したより複雑な例

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

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

    return &p, nil
}

エラー装飾をサポートしているが、より大幅な言語変更が必要な（明らかにgo1.10ではない）単純なアイデアは、新しいcheckキーワードの導入です。

check Aとcheck A, B 2つの形式になります。

どちらもAとBする必要がerror 。 2番目の形式は、エラーを装飾する場合にのみ使用されます。 エラーを装飾する必要がない、または装飾したくない人は、より単純な形式を使用します。

第1形態（チェックA）

check AはA評価します。 nil場合、何もしません。 nilでない場合、 checkはreturn {<zero>}*, Aます。

例

• 関数がエラーを返すだけの場合は、 checkとインラインで使用できるため、

err := UpdateDB()    // signature: func UpdateDb() error
if err != nil {
    return err
}

になります

check UpdateDB()

• 複数の戻り値を持つ関数の場合、現在のように割り当てる必要があります。

a, b, err := Foo()    // signature: func Foo() (string, string, error)
if err != nil {
    return "", "", err
}

// use a and b

になります

a, b, err := Foo()
check err

// use a and b

2番目のフォーム（チェックA、B）

check A, BはA評価します。 nil場合、何もしません。 nilでない場合、 checkはreturn {<zero>}*, Bます。

これは、エラーを装飾するためのものです。 引き続きAチェックしますが、暗黙のreturn使用されるのはBです。

例

a, err := Bar()    // signature: func Bar() (string, error)
if err != nil {
    return "", &BarError{"Bar", err}
}

になります

a, err := Foo()
check err, &BarError{"Bar", err}

ノート

コンパイルエラーです

• error評価されないものには、 checkステートメントを使用します
• { type }*, error形式ではない戻り値を持つ関数でcheckを使用します

2つのexpr形式のcheck A, Bが短絡しています。 B Aがnil場合、 Bは評価されません。

実用性に関する注意

エラーの装飾はサポートされていますが、実際にエラーを装飾する必要がある場合にのみ、より不格好なcheck A, B構文の料金を支払います。

if err != nil { return nil, nil, err }ボイラープレート（これは非常に一般的です）の場合、 check errは、明確さを犠牲にすることなく、可能な限り簡潔になります（以下の構文に関する注記を参照）。

構文に関する注意

この種の構文（ check .. 、行の先頭、 returnと同様）は、制御フローの中断を隠すことなく、ボイラープレートのエラーチェックを排除するための良い方法であると私は主張します。暗黙のリターンが導入されます。

上記の<do-stuff> || <handle-err>や<do-stuff> catch <handle-err> 、または別のスレッドで提案されたa, b = foo()?ようなアイデアの欠点は、フローを困難にする方法で制御フローの変更を非表示にすることです。フォローする; 前者は、他の点ではわかりやすい行の最後に|| <handle-err>機械が追加され、後者は、コードのわかりやすい行の中央と最後を含め、どこにでも表示できる小さな記号が付いています。おそらく複数回。

checkステートメントは常に現在のブロックの最上位にあり、制御フローを変更する他のステートメントと同じように目立ちます（たとえば、初期のreturn ）。

@ALTree 、私はあなたの例がどのように理解できませんでした：

a, b, err := Foo()
check err

オリジナルからの3つの価値のあるリターンを実現します。

return "", "", err

最終エラーを除いて、宣言されたすべての戻り値に対してゼロ値を返すだけですか？ Write（）が失敗したときに書き込まれたバイト数など、エラーとともに有効な値を返したい場合はどうでしょうか。

どのソリューションを使用する場合でも、エラー処理の一般性を最小限に制限する必要があります。

行の先頭にcheckがあることの価値に関して、私の個人的な好みは、各行の先頭にプライマリ制御フローを表示し、エラー処理がそのプライマリ制御フローの可読性をほとんど妨げないようにすることです。できるだけ。 また、エラー処理がcheckやcatchような予約語で区別されている場合、ほとんどすべての最新のエディターは、何らかの方法で予約語の構文を強調表示し、それを目立たせます。右側にある場合。

@billyhこれは、上記の次の行で説明されています。

nilでない場合、チェックはreturn {<zero>}*, A

checkは、エラー（最後の位置）を除いて、任意の戻り値のゼロ値を返します。

エラーとともに有効な値を返したい場合はどうでしょうか

次に、 if err != nil {イディオムを使用します。

より高度なエラー回復手順が必要になる場合が多くあります。 たとえば、エラーをキャッチした後、何かをロールバックしたり、ログファイルに何かを書き込んだりする必要がある場合があります。 これらすべての場合でも、ツールボックスには通常のif errイディオムがあり、それを使用して新しいブロックを開始できます。ここで、エラー処理に関連するあらゆる種類の操作が、明確に表現されていても可能です。実行されます。

どのソリューションを使用する場合でも、エラー処理の一般性を最小限に制限する必要があります。

上記の私の答えを参照してください。 あなたはまだifと言語が今あなたに与える他のものを持っているでしょう。

ほとんどすべての現代の編集者は予約語を強調しようとしています

多分。 しかし、読みやすくするために構文の強調表示を必要とする不透明な構文を導入することは理想的ではありません。

この特定のバグは、言語にダブルリターン機能を導入することで修正できます。
この場合、関数a（）は123を返します。

func a（）int {
b（）
456を返す
}
func b（）{
return return int（123）
}

この機能は、次のようにエラー処理を簡素化するために使用できます。

func handle（var * foo、err error）（var * foo、err error）{
err！= nil {の場合
return return nil、err
}
var、nilを返す
}

func client_code（）（* client_object、error）{
var obj、err = handle（something_that_can_fail（））
//これは何かが失敗しなかった場合にのみ到達します
//それ以外の場合、client_code関数はエラーをスタックに伝播します
assert（err == nil）
}

これにより、エラーをスタックに伝播できるエラーハンドラー関数を作成できます。
このようなエラー処理関数は、メインコードから分離できます

間違えた場合は申し訳ありませんが、要点を明確にしたいのですが、以下の関数はエラー、 vet警告を生成しますか、それとも受け入れられますか？

func Chdir(dir string) (err error) {
    syscall.Chdir(dir) || err
    return nil
}

@rodcorsiこの提案では、あなたの例は獣医の警告なしに受け入れられます。 と同等になります

if err := syscall.Chdir(dir); err != nil {
    return err
}

エラーを処理するためにコンテキストの使用を拡張するのはどうですか？ たとえば、次の定義が与えられます。
type ErrorContext interface { HasError() bool SetError(msg string) Error() string }
エラーが発生しやすい関数になりました...
func MyFunction(number int, ctx ErrorContext) int { if ctx.HasError() { return 0 } return number + 1 }
中間機能では..。
func MyIntermediateFunction(ctx ErrorContext) int { if ctx.HasError() { return 0 } number := 0 number = MyFunction(number, ctx) number = MyFunction(number, ctx) number = MyFunction(number, ctx) return number }
そして上位レベルの機能では
func main() { ctx := context.New() no := MyIntermediateFunction(ctx) if ctx.HasError() { log.Fatalf("Error: %s", ctx.Error()) return } fmt.Printf("%d\n", no) }
このアプローチを使用すると、いくつかの利点があります。 まず、リーダーがメインの実行パスから気を散らすことはありません。 メインの実行パスからの逸脱を示す最小限の「if」ステートメントがあります。

第二に、それはエラーを隠しません。 メソッドシグネチャから、ErrorContextを受け入れる場合、関数にエラーがある可能性があることは明らかです。 関数内では、通常のGoコードを使用してエラーがどのように処理されるかを示す通常の分岐ステートメント（「if」など）を使用します。

第3に、エラーは自動的に関係者（この場合はコンテキスト所有者）にバブルされます。 追加のエラー処理がある場合は、明確に表示されます。 たとえば、既存のエラーをラップするために、中間関数にいくつかの変更を加えましょう。
func MyIntermediateFunction(ctx ErrorContext) int { if ctx.HasError() { return 0 } number := 0 number = MyFunction(number, ctx) number = MyFunction(number, ctx) number = MyFunction(number, ctx) if ctx.HasError() { ctx.SetError(fmt.Sprintf("wrap msg: %s", ctx.Error()) return } number *= 20 number = MyFunction(number, ctx) return number }
基本的には、必要に応じてエラー処理コードを記述するだけです。 手動でバブルする必要はありません。

最後に、関数の作成者であるあなたは、エラーを処理する必要があるかどうかを判断できます。 現在のGoアプローチを使用すると、これを行うのは簡単です...
`` ``
//次の定義が与えられた
func MyFunction（number int）エラー

//次にこれを行います
MyFunction（8）//エラーをチェックせずに
With the ErrorContext, you as the function owner can make the error checking optional with this:
func MyFunction（ctx ErrorContext）{
if ctx！= nil && ctx.HasError（）{
戻る
}
//..。
}
Or make it compulsory with this:
func MyFunction（ctx ErrorContext）{
if ctx.HasError（）{// ctxがnilの場合はパニックになります
戻る
}
//..。
}
If you make error handling compulsory and yet the user insists on ignoring error, they can still do that. However, they have to be very explicit about it (to prevent accidental ignore). For instance:
func UpperFunction（ctx ErrorContext）{
無視されます：= context.New（）
MyFunction（ignored）//これは無視されます

 MyFunction(ctx) //this one is handled

}
`` ``
このアプローチは、既存の言語に何も変更しません。

@ALTree Alberto、 checkと@ianlancetaylorが提案したものを

それで

func F() (int, string, error) {
   i, s, err := OhNo()
   if err != nil {
      return i, s, &BadStuffHappened(err, "oopsie-daisy")
   }
   // all is good
   return i+1, s+" ok", nil
}

になります

func F() (int, string, error) {
   i, s, err := OhNo()
   check i, s, err || &BadStuffHappened(err, "oopsie-daisy")
   // all is good
   return i+1, s+" ok", nil
}

また、 checkを制限してエラータイプのみを処理できるため、複数の戻り値が必要な場合は、それらに名前を付けて割り当てる必要があります。これにより、何らかの方法で「インプレース」が割り当てられ、単純な「戻り」のように動作します。

func F() (a int, s string, err error) {
   i, s, err = OhNo()
   check err |=  &BadStuffHappened(err, "oopsy-daisy")  // assigns in place and behaves like simple "return"
   // all is good
   return i+1, s+" ok", nil
}

returnがいつか式で受け入れられるようになる場合、 checkは不要であるか、標準関数になります

func check(e error) bool {
   return e != nil
}

func F() (a int, s string, err error) {
   i, s, err = OhNo()
   check(err) || return &BadStuffHappened(err, "oopsy-daisy")
   // all is good
   return i+1, s+" ok", nil
}

最後の解決策はPerlのように感じますが😄

誰が最初にそれを提案したのか思い出せませんが、ここに別の構文のアイデアがあります（みんなのお気に入りの自転車小屋:-)。 良いものだと言っているわけではありませんが、アイデアをポットに投げ込んでいるのなら...

x, y := try foo()

と同等になります：

x, y, err := foo()
if err != nil {
    return (an appropriate number of zero values), err
}

と

x, y := try foo() catch &FooErr{E:$, S:"bad"}

と同等になります：

x, y, err := foo()
if err != nil {
    return (an appropriate number of zero values), &FooErr{E:err, S:"bad"}
}

try形式は確かに以前に提案されており、何度も、モジュロ表面的な構文の違いがあります。 try ... catch形式はあまり提案されませんが、 @ ALTreeのcheck A, B構造と@tandrのフォローアップ提案に明らかに似ています。 1つの違いは、これはステートメントではなく式であるため、次のように言うことができます。

z(try foo() catch &FooErr{E:$, S:"bad"})

1つのステートメントに複数のtry / catchを含めることができます。

p = try q(0) + try q(1)
a = try b(c, d() + try e(), f, try g() catch &GErr{E:$}, h()) catch $BErr{E:$}

私たちはそれを奨励したいとは思いませんが。 ここでも、評価の順序に注意する必要があります。 たとえば、 e()がnil以外のエラーを返した場合に、 h()が副作用について評価されるかどうか。

明らかに、 tryやcatchような新しいキーワードは、Go1.xの互換性を壊します。

私は、この提案の対象を絞るべきだと提案します。 この提案によってどのような問題が修正されますか？ 次の3行を2行または1行に減らしますか？ これは、return / ifの言語の変更である可能性があります。

if err != nil {
    return err
}

または、エラーをチェックする回数を減らしますか？ これに対するtry / catchソリューションかもしれません。

エラー処理のための合理的なショートカット構文には、次の3つのプロパティがあることをお勧めします。

1. エラーのないパスが目立つように、チェックしているコードの前に表示しないでください。
2. 同じ名前の明示的な変数がある場合に読者が混乱しないように、スコープに暗黙的な変数を導入するべきではありません。
3. ある回復アクション（たとえば、 return err ）を別のアクションよりも簡単にするべきではありません。 まったく異なるアクションが望ましい場合もあります（ t.Fatal呼び出しなど）。 また、コンテキストを追加することを人々に思いとどまらせたくありません。

これらの制約を考えると、ほぼ最小限の構文の1つは次のようになります。

STMT SEPARATOR_TOKEN VAR BLOCK

例えば、

syscall.Chdir(dir) :: err { return err }

これは

if err := syscall.Chdir(dir); err != nil {
    return err
}
````
Even though it's not much shorter, the new syntax moves the error path out of the way. Part of the change would be to modify `gofmt` so it doesn't line-break one-line error-handling blocks, and it indents multi-line error-handling blocks past the opening `}`.

We could make it a bit shorter by declaring the error variable in place with a special marker, like

syscall.Chdir（dir）:: {return @err }
`` `

ゼロ以外の値とエラーの両方が返された場合、これはどのように動作するのでしょうか。 たとえば、bufio.Peekは、ゼロ以外の値とErrBufferFullの両方を同時に返す可能性があります。

@mattnは、引き続き古い構文を使用できます。

@nigeltaoはい、わかりました。 bufio.Peekもゼロ以外とnilを返すため、この動作によってユーザーのコードにバグが生じる可能性があると思われます。 コードは、値とエラーの両方を暗黙的に使用してはなりません。 したがって、値とエラーの両方を呼び出し元（この場合）に返す必要があります。

ret, err := doSomething() :: err { return err }
return ret, err

@jbaあなたが説明していることは、転置された関数合成演算子に少し似ています：

syscall.Chdir(dir) ⫱ func (err error) { return &PathError{"chdir", dir, err} }

しかし、私たちがほとんど命令型のコードを書いているという事実は、ポイントの一部が早期に戻ることができるようにすることであるため、2番目の位置で関数を使用しないことを必要とします。

だから今、私はすべての種類に関連している3つの観察について考えています：

1. エラー処理は関数合成に似ていますが、Goでの処理方法は、HaskellのErrorモナドとは逆です。シーケンシャルコードではなく命令型を記述しているため、エラーを変換する（コンテキストを追加する）必要があります。エラー以外の値（変数にバインドするだけです）。

2. (x, y, error)を返すGo関数は、通常、実際には(x, y) | error和集合（＃19412）のようなものを意味します。

3. ユニオンをアンパックまたはパターンマッチングする言語では、ケースは個別のスコープであり、Goでのエラーで発生する問題の多くは、再宣言された変数の予期しないシャドウイングが原因であり、これらのスコープを分離することで改善される可能性があります（＃21114）。

したがって、実際に必要なのは=:演算子のようなものですが、一種のユニオンマッチング条件付きです。

syscall.Chdir(dir) =? err { return &PathError{"chdir", dir, err} }

`` `行く
n：= io.WriteString（w、s）=？ err {returnerr}

and perhaps a boolean version for `, ok` index expressions and type assertions:
```go
y := m[x] =! { return ErrNotFound }

スコーピングを除いて、それは単にgofmtをワンライナーにもっと従順に変更することと大差ありません：

err := syscall.Chdir(dir); if err != nil { return &PathError{"chdir", dir, err} }

`` `行く
n、err：= io.WriteString（w、s）; if err！= nil {returnerr}

```go
y, ok := m[x]; if !ok { return ErrNotFound }

しかし、スコーピングは大したことです！ スコープの問題は、この種のコードが「やや醜い」から「微妙なバグ」へと一線を越えるところです。

@ianlancetaylor
私は全体的なアイデアのファンですが、そのための不可解なperlのような構文を大いに支持しているわけではありません。 おそらく、次のように、より単語の多い構文の方が混乱が少ないでしょう。

syscall.Chdir(dir) or dump(err): errors.Wrap(err, "chdir failed")

syscall.Chdir(dir) or dump

また、割り当ての場合に最後の引数がポップされるかどうかもわかりませんでした。例：

resp := http.Get("https://example.com") or dump

エラーはgoの値であり、特別なタイプではないことを忘れないでください。
エラーやその逆に対して実行できない他の構造体に対して実行できることは何もありません。 これは、構造体を一般的に理解していれば、エラーとその処理方法を理解していることを意味します（冗長だと思っていても）

この構文では、新旧の開発者が、それを使用するコードを理解し始める前に、新しい情報を学ぶ必要があります。

それだけでは、この提案は私見の価値がありません。

個人的にはこの構文が好きです

err := syscall.Chdir(dir)
if err != nil {
    return err
}
return nil

以上

if err := syscall.Chdir(dir); err != nil {
    return err
}
return nil

これはもう1行ですが、意図したアクションとエラー処理を分離しています。 このフォームは私にとって最も読みやすいものです。

@bcmills ：

スコーピングを除いて、それは単にgofmtをワンライナーにもっと従順に変更することと大差ありません

スコーピングだけではありません。 左端もあります。 それは本当に読みやすさに影響すると思います。 私が思うに

syscall.Chdir(dir) =: err; if err != nil { return &PathError{"chdir", dir, err} } 

よりもはるかに明確です

err := syscall.Chdir(dir); if err != nil { return &PathError{"chdir", dir, err} } 

特に、複数の連続した行で発生する場合は、目が左端をスキャンしてエラー処理を無視できるためです。

@bcmillsのアイデアを

最後の値がnilでF2関数が実行されます。

func F1() (foo, bar){}

first := F1() ?> last: F2(first, last)

returnステートメントを使用したパイプ転送の特殊なケース

func Chdir(dir string) error {
    syscall.Chdir(dir) ?> err: return &PathError{"chdir", dir, err}
    return nil
}

別の問題で@urandomによってもたらされた実際の例
私にとっては、プライマリフローに焦点を当てるとはるかに読みやすくなります

func configureCloudinit(icfg *instancecfg.InstanceConfig, cloudcfg cloudinit.CloudConfig) (cloudconfig.UserdataConfig, error) {
    // When bootstrapping, we only want to apt-get update/upgrade
    // and setup the SSH keys. The rest we leave to cloudinit/sshinit.
    udata := cloudconfig.NewUserdataConfig(icfg, cloudcfg) ?> err: return nil, err
    if icfg.Bootstrap != nil {
        udata.ConfigureBasic() ?> err: return nil, err
        return udata, nil
    }
    udata.Configure() ?> err: return nil, err
    return udata, nil
}

func ComposeUserData(icfg *instancecfg.InstanceConfig, cloudcfg cloudinit.CloudConfig, renderer renderers.ProviderRenderer) ([]byte, error) {
    if cloudcfg == nil {
        cloudcfg = cloudinit.New(icfg.Series) ?> err: return nil, errors.Trace(err)
    }
    _ = configureCloudinit(icfg, cloudcfg) ?> err: return nil, errors.Trace(err)
    operatingSystem := series.GetOSFromSeries(icfg.Series) ?> err: return nil, errors.Trace(err)
    udata := renderer.Render(cloudcfg, operatingSystem) ?> err: return nil, errors.Trace(err)
    logger.Tracef("Generated cloud init:\n%s", string(udata))
    return udata, nil
}

エラー処理は人間工学的ではないことに同意します。 つまり、以下のコードを読むときは、それをif error not nil thenに発声する必要があります。これは、 if there is an error then変換されます。

if err != nil {
    // handle error
}

私はそのような方法で上記のコードを表現する能力を持ちたいと思っています-私の意見ではもっと読みやすいです。

if err {
    // handle error
}

ただ私の謙虚な提案:)

それはperlのように見えます、それは魔法の変数さえ持っています
参考までに、perlでは

open（FILE、$ file）またはdie（ "cannot open $ file：$！"）;

私見、それは価値がありません、私が行くことについて好きな1つのポイントはそのエラー処理です
明示的で「あなたの顔に」

私たちがそれに固執するなら、私は魔法の変数を持たないようにしたいのです、私たちは
エラー変数に名前を付けることができます

e：= syscall.Chdir（dir）？> e：＆PathError {"chdir"、dir、e}

また、||とは異なる記号を使用することもできます。 このタスクに固有の、
'や'のようなテキスト記号は後方にあるため不可能だと思います
互換性

n、_、err、_ = somecall（...）？> err：＆PathError {"somecall"、n、err}

14:47で火、2017年8月1日には、ロドリゴの[email protected]は書きました：

アイデアを混ぜる@bcmillshttps ：//github.com/bcmills紹介できる
条件付きパイプ転送演算子。

最後の値がnilで

func F1（）（foo、bar）{}
最初：= F1（）？>最後：F2（最初、最後）

returnステートメントを使用したパイプ転送の特殊なケース

func Chdir（dir string）エラー{
syscall.Chdir（dir）？> err：return＆PathError {"chdir"、dir、err}
nilを返す
}

実際の例
https://github.com/juju/juju/blob/01b24551ecdf20921cf620b844ef6c2948fcc9f8/cloudconfig/providerinit/providerinit.go
別の問題で@urandomhttps ：//github.com/urandomによってもたらされました
私にとっては、プライマリフローに焦点を当てるとはるかに読みやすくなります

func configureCloudinit（icfg * instancecfg.InstanceConfig、cloudcfg cloudinit.CloudConfig）（cloudconfig.UserdataConfig、error）{
//ブートストラップするときは、apt-get update / upgradeのみが必要です
// SSHキーを設定します。 残りはcloudinit / sshinitに任せます。
udata：= cloudconfig.NewUserdataConfig（icfg、cloudcfg）？> err：return nil、err
if icfg.Bootstrap！= nil {
udata.ConfigureBasic（）？> err：nil、errを返します
udata、nilを返します
}
udata.Configure（）？> err：nil、errを返します
udata、nilを返します
}
func ComposeUserData（icfg * instancecfg.InstanceConfig、cloudcfg cloudinit.CloudConfig、renderer renderers.ProviderRenderer）（[] byte、error）{
cloudcfg == nil {の場合
cloudcfg = cloudinit.New（icfg.Series）？> err：return nil、errors.Trace（err）
}
configureCloudinit（icfg、cloudcfg）？> err：nil、errors.Trace（err）を返します
OperatingSystem：= series.GetOSFromSeries（icfg.Series）？> err：return nil、errors.Trace（err）
udata：= renderer.Render（cloudcfg、operationingSystem）？> err：return nil、errors.Trace（err）
logger.Tracef（ "生成されたクラウドの初期化：\ n％s"、string（udata））
udata、nilを返します
}

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

これらの提案されたすべての変更が現在の形式よりも複雑になると考えるのは私だけですか。

単純さと簡潔さは同等でも互換性もないと思います。 はい、これらの変更はすべて1行以上短くなりますが、言語のユーザーが学習する必要のある演算子またはキーワードが導入されます。

@rodcorsiマイナーに見えることは知っていますが、2番目の部分がブロックであることが重要だと思います。既存のif forステートメントとselectとswitchどちらも中括弧で区切られた構文を使用するため、この1つの特定の制御フロー操作で中括弧を省略するのは厄介なようです。

また、新しいシンボルに続く任意の式について心配する必要がない場合は、解析ツリーが明確であることを確認する方がはるかに簡単です。

スケッチで念頭に置いていた構文とセマンティクスは次のとおりです。

NonZeroGuardStmt = ( Expression | IdentifierList ":=" Expression |
                     ExpressionList assign_op Expression ) "=?" [ identifier ] Block .
ZeroGuardStmt = ( Expression | IdentifierList ":=" Expression |
                  ExpressionList assign_op Expression ) "=!" Block .

Expressionの最後の値がそのタイプのゼロ値と等しくない場合、 NonZeroGuardStmtはBlock NonZeroGuardStmt実行します。 identifierが存在する場合、 Block内のその値にバインドされます。 Expressionの最後の値がそのタイプのゼロ値と等しい場合、 ZeroGuardStmtはBlock ZeroGuardStmt実行します。

以下のために:=形態の他の（リーディング）の値Expressionに結合しているIdentifierListのようにShortVarDecl 。 識別子は包含スコープで宣言されます。これは、識別子がBlock内にも表示されることを意味します。

assign_op形式の場合、左側の各オペランドは、アドレス可能、マップインデックス式、または（ =割り当ての場合のみ）空白の識別子である必要があります。 オペランドは括弧で囲むことができます。 右側のExpressionの他の（先頭の）値は、 Assignmentように評価されます。 割り当ては、 Block実行前に、 Blockが実行されるかどうかに関係なく行われます。

ここで提案されている文法はGo1と互換性があると思います。 ?は有効な識別子ではなく、その文字を使用する既存のGo演算子はありません。また、 !は有効な演算子ですが、 {が後に続く可能性のある既存のプロダクション。

@bcmills LGTM、gofmtへの付随する変更。

=?と=!それぞれそれ自体でトークンにすると、文法の互換性が簡単になると思います。

私はあなたが=を作ると思ったでしょう？ および=！ それぞれのトークンはそれ自体で、文法の互換性を簡単にします。

これは文法では実行できますが、字句解析では実行できません。シーケンス「=！」 有効なGo1コード（https://play.golang.org/p/pMTtUWgBN9）で表示できます。

中括弧は、私の提案で解析を明確にするものです。 =!は現在、ブール変数の宣言または代入にのみ表示でき、宣言と代入は現在、中括弧の直前に表示できません（https暗黙のセミコロン（https://play.golang.org/p/lhcqBhr7Te）で区切られていない限り、：//play.golang.org/p/ncJyg-GMuL）。

@romainmenkeいいえ。 あなただけではありません。 ワンライナーエラー処理の価値がわかりません。 1行節約できますが、さらに複雑になります。 問題は、これらの提案の多くで、エラー処理部分が隠れてしまうことです。 エラー処理が重要であるため、それらを目立たなくするのではなく、コードを読みやすくするという考え方です。 簡潔さは読みやすさと同じではありません。 既存のエラー処理システムに変更を加える必要がある場合は、従来のtry-catch-finallyの方が、ここでの多くのアイデアの目的よりもはるかに魅力的だと思います。

check提案が気に入ったのは、それを拡張して処理することもできるからです。

f, err := os.Open(myfile)
check err
defer check f.Close()

他の提案もdeferと混同できるようには見えません。 checkも非常に読みやすく、知らない場合はGoogleにとって簡単です。 errorタイプに限定する必要はないと思います。 最後の位置の戻りパラメーターであるものはすべてそれを使用できます。 だから、反復子は、必要がある場合がありますcheckについてNext() bool 。

私はかつて次のようなスキャナーを作成しました

func (s *Scanner) Next() bool {
    if s.Error != nil || s.pos >= s.RecordCount {
        return false
    }
    s.pos++

    var rt uint8
    if !s.read(&rt) {
        return false
    }
...

その最後のビットは、代わりにcheck s.read(&rt)可能性があります。

@carlmjohnson

他の提案もdeferと混同できるようには見えません。

deferを拡張して、新しい構文を使用して外部関数から戻ることができると想定している場合は、その想定を他の提案にも同様に適用できます。

defer f.Close() =? err { return err }

@ALTreeのcheck提案では別のステートメントが導入されているため、単にエラーを返す以外のことを行うdeferとそれを組み合わせる方法がわかりません。

defer func() {
  err := f.Close()
  check err, fmt.Errorf(…, err) // But this func() doesn't return an error!
}()

対比：

defer f.Close() =? err { return fmt.Errorf(…, err) }

これらの提案の多くの正当性は、より優れた「人間工学」ですが、それを作成する以外に、これらのいずれかがどのように優れているかは実際にはわかりません。 これらはどのようにコードの保守性を向上させますか？ 構成可能性？ 読みやすさ？ 制御フローの理解のしやすさ？

@jimmyfrasche

これらはどのようにコードの保守性を向上させますか？ 構成可能性？ 読みやすさ？ 制御フローの理解のしやすさ？

前に述べたように、これらの提案の主な利点は、おそらく割り当てとerr変数のより明確なスコープから来る必要があります：＃19727、＃20148、＃5634、＃21114、およびおそらく他のさまざまなものを参照してくださいエラー処理に関連して人々がスコーピングの問題に遭遇する方法。

@bcmillsはモチベーションを提供してくれてありがとう、そして申し訳ありませんがあなたの以前の投稿でそれを逃しました。

ただし、その前提を考えると、すべての変数で使用できる「割り当てのより明確なスコープ」のためのより一般的な機能を提供する方がよいのではないでしょうか。 確かに、エラー以外の変数のシェアも意図せずにシャドウイングしました。

:=の現在の動作が導入されたときのことを覚えています。そのスレッドの多くは、暗黙の「変数が存在する場合にのみ再利用する」の代わりに、再利用する名前に明示的に注釈を付ける方法を求めていました。私の経験では、すべての微妙な見にくい問題が現れる場所である「正確に現在の範囲」。

†そのスレッドを見つけることができません誰かがリンクを持っていますか？

Goについては改善できると思うことがたくさんありますが、 :=の動作は、常に1つの重大な間違いとして私を驚かせました。 たぶん、 :=の動作を再検討することは、根本的な問題を解決する方法、または少なくとも他のより極端な変更の必要性を減らす方法ですか？

@jimmyfrasche

ただし、その前提を考えると、すべての変数で使用できる「割り当てのより明確なスコープ」のためのより一般的な機能を提供する方がよいのではないでしょうか。

はい。 これは、 @ jbaと私が提案した=?または::演算子について私が気に入っていることの1つです。これは、非エラー（明らかに限定されたサブセット）にもうまく拡張されます。

個人的には、より明示的なタグ付き共用体/変数/代数的データ型機能（＃19412も参照）を使用すると、長期的には幸せになると思いますが、それは言語に対するはるかに大きな変更です。これは、Go 1 / Go2が混在する環境の既存のAPIに適用されます。

制御フローの理解のしやすさ？

私と@bcmillsの提案では、あなたの目は左側をスキャンして、エラーのない制御フローを簡単に取り込むことができます。

@ bcmills ＃19412の単語の少なくとも半分は私が担当していると思うので、合計タイプで私を売る必要はありません;）

エラーのあるものを返すことになると、4つのケースがあります

1. ただのエラー（何もする必要はありません、ただエラーを返すだけです）
2. スタッフとエラー（今とまったく同じように処理します）
3. 1つまたはエラー（合計タイプを使用できます！：tada :)
4. 2つ以上のものまたはエラー

あなたが4を打った場合、それは物事がトリッキーになるところです。 タプルタイプ（構造体のラベル付き製品タイプに対応するラベルなし製品タイプ）を導入せずに、合計タイプを使用して「これまたはエラー」をモデル化する場合は、構造体にすべてをバンドルして、問題をケース3に減らす必要があります。

タプルタイプを導入すると、あらゆる種類の問題や互換性の問題、奇妙な重複が発生します（ func() (int, string, error)は暗黙的に定義されたタプルですか、それとも複数の戻り値は別の概念ですか？暗黙的に定義されたタプルの場合、それはfunc() (n int, msg string, err error)を意味しますか？

合計タイプにはまだ多くの利点があると思いますが、もちろん、スコープの問題を修正するために何もしません。 結果のケースに何かがあったときにエラーのケースを単にシャドウイングするのではなく、「結果またはエラー」の合計全体をシャドウイングできるため、どちらかといえば悪化する可能性があります。

@jbaそれがどのように望ましい特性であるかわかりません。 制御フローを2次元にするという概念の一般的な難しさを除けば、いわば、なぜそうでないのか、私にはよくわかりません。 メリットを説明してもらえますか？

タプルタイプを導入せずに[…]合計タイプを使用して「これまたはエラー」をモデル化する場合は、構造体にすべてを[バンドル]する必要があります。

私はそれで大丈夫です：私たちはその方法ではるかに読みやすい呼び出しサイトを持っていると思います（誤って転置された位置バインディングはもうありません！）、そして＃12854は現在構造体の戻りに関連するオーバーヘッドの多くを軽減します。

大きな問題は移行です。Go1の「値とエラー」モデルからGo2の潜在的な「値またはエラー」モデルにどのように移行するのでしょうか。特に、実際に「値」を返すio.WriterようなAPIを考えるととエラー」？

合計タイプにはまだ多くの利点があると思いますが、もちろん、スコープの問題を修正するために何もしません。

それはあなたがそれらをどのように開梱するかに依存します、それは私たちを今日の場所に戻すと私は思います。 ユニオンを好む場合は、 =?バージョンを「非対称パターンマッチング」APIとして想定できます。

i := match strconv.Atoi(str) | err error { return err }

ここで、 matchは従来のMLスタイルのパターン一致操作ですが、非網羅的な一致の場合は値を返します（ユニオンに一致しない選択肢が複数ある場合はinterface{}として）網羅的ではない試合の失敗で慌てるのではなく。

ここで説明されている問題にプログラムで対処するパッケージをhttps://github.com/mpvl/errdでチェックインしました（言語の変更はありません）。 このパッケージの最も重要な側面は、エラー処理を短縮するだけでなく、正しく実行しやすくすることです。 特にdeferとの相互作用において、従来の慣用的なエラー処理が見た目よりもトリッキーである方法について、ドキュメントで例を示します。

ただし、これは「バーナー」パッケージだと思います。 目的は、言語を拡張するための最良の方法について、いくつかの良い経験と洞察を得ることです。 これが問題になるのであれば、ジェネリックと非常によく相互作用します。

まだいくつかの例に取り組んでいますが、このパッケージは実験する準備ができています。

@bcmills a million：+1：for＃12854

お気づきのように、「return Xanderror」と「returnXor error」があるので、古い方法を新しい方法にオンデマンドで変換するマクロがなければ、それを回避することはできません（もちろんバグがあります）または、「X and error」関数に必然的に使用された場合、少なくともランタイムはパニックになります）。

特にエラー処理のためだけに特別なマクロを言語に導入するというアイデアは本当に好きではありません。これは、これらの提案の多くでの私の大きな問題です。

砂糖や魔法は大したことではなく、それはプラスです。

現在の慣性では、より機能的なエラー処理パラダイムへの大規模な飛躍を処理するには、慣性が大きすぎ、情報が少なすぎます。

Go 2が合計タイプを取得した場合（率直に言って（良い意味で！））、「新しいスタイル」に移行するには、どちらかといえば、非常にゆっくりとした段階的なプロセスである必要があります。エラーの処理方法の断片化と混乱が増えているため、正味のポジティブではないと思います。 （ただし、3つのチャネルではなくchan union { Msg1 T; Msg2 S; Err error }ようなものにすぐに使用し始めます）。

これがGo1以前であり、Goチームが「次の6か月間、すべてを移動し、問題が発生した場合は維持する」と言うことができれば、それは1つのことですが、現在は基本的に行き詰まっています。合計タイプを取得したとしても。

お気づきのように、「return Xanderror」と「returnXor error」があるので、古い方法を新しい方法にオンデマンドで変換するマクロがなければ、それを回避することはできません。

上で述べたように、新しい方法では、それが何であれ、「Xとエラーを返す」をカバーする必要はないと思います。 大多数のケースが「Xまたはエラーを返す」であり、新しい方法がそれだけを改善する場合、それは素晴らしいことであり、よりまれな「Xおよびエラーを返す」ために古いGo1互換の方法を引き続き使用できます。

@nigeltao本当ですが、標準ライブラリ全体を既存のスタイルで維持することを提案しない限り、移行中にそれらを区別するための何らかの方法が必要です。

@jimmyfrasche私はそれについての議論を構築することはできないと思います。 私の話を見るか、リポジトリのREADMEで例を見ることができ

@jbaは講演を見て、READMEを読みました。 私はあなたが括弧/脚注/文末脚注/サイドノートのことでどこから来ているのか理解しました（そして私はサイドノート（および括弧）のファンです）。

より良い用語がないために、側に不幸な道を置くことが目標である場合、$ EDITORプラグインは言語を変更せずに機能し、コードの作成者の好みに関係なく、既存のすべてのコードで機能します。

言語の変更により、構文がいくらかコンパクトになります。 @bcmillsは、これによりスコープが改善されると述べていますが、 :=とは異なるスコープ規則がない限り、どのようにできるかはわかりませんが、混乱が生じるようです。

@bcmillsあなたのコメントがわかりません。 あなたは明らかにそれらを区別することができます。 古い方法は次のようになります。

err := foo()
if err != nil {
  return n, err  // n can be non-zero
}

新しい方法は次のようになります

check foo()

また

foo() || &FooError{err}

またはバイクシェッドの色が何であれ。 標準ライブラリのほとんどは移行できると思いますが、すべてが移行できるわけではありません。

@ianlancetaylorの要件に追加するには、エラーメッセージを単純化することで、物事を短くするだけでなく、エラー処理を簡単に行うことができます。 パニックとダウンストリームエラーを関数を延期するまで渡すのは、正しく行うのが難しいです。

たとえば、エラーが発生した場合にファイルの書き込みを中止するGoogle CloudStorageファイルへの書き込みについて考えてみます。

func writeToGS(ctx context.Context, bucket, dst string, r io.Reader) (err error) {
    client, err := storage.NewClient(ctx)
    if err != nil {
        return err
    }
    defer client.Close()

    w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
    defer func() {
        if r := recover(); r != nil {
            w.CloseWithError(fmt.Errorf("panic: %v", r))
            panic(r)
        }
        if err != nil {
            _ = w.CloseWithError(err)
        } else {
            err = w.Close()
        }
    }
    _, err = io.Copy(w, r)
    return err
}

このコードの微妙な点は次のとおりです。

• Copyからのエラーは、名前付きのreturn引数を介してdefer関数にこっそり渡されます。
• 完全に安全にするために、rからのパニックをキャッチし、パニックを再開する前に書き込みを中止するようにします。
• 最初のCloseのエラーを無視することは意図的なものですが、ちょっと怠惰なプログラマーのアーティファクトのように見えます。

パッケージerrdを使用すると、このコードは次のようになります。

func writeToGS(ctx context.Context, bucket, dst, src string, r io.Reader) error {
    return errd.Run(func(e *errd.E) {
        client, err := storage.NewClient(ctx)
        e.Must(err)
        e.Defer(client.Close, errd.Discard)

        w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
        e.Defer(w.CloseWithError)

        _, err = io.Copy(w, r)
        e.Must(err)
    })
}

errd.Discardはエラーハンドラーです。 エラーハンドラーを使用して、エラーをラップ、ログに記録することもできます。

e.Mustはfoo() || wrapError相当します

e.Deferは余分であり、遅延へのエラーの受け渡しを処理します。

ジェネリックスを使用すると、このコードは次のようになります。

func writeToGS(ctx context.Context, bucket, dst, src string, r io.Reader) error {
    return errd.Run(func(e *errd.E) {
        client := e.Must(storage.NewClient(ctx))
        e.Defer(client.Close, errd.Discard)

        w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
        e.Defer(w.CloseWithError)

        _ = e.Must(io.Copy(w, r))
    })
}

Deferに使用するメソッドを標準化すると、次のようになります。

func writeToGS(ctx context.Context, bucket, dst, src string, r io.Reader) error {
    return errd.Run(func(e *errd.E) {
        client := e.DeferClose(e.Must(storage.NewClient(ctx)), errd.Discard)
       e.Must(io.Copy(e.DeferClose(client.Bucket(bucket).Object(dst).NewWriter(ctx)), r)
    })
}

DeferCloseは、CloseまたはCloseWithErrorのいずれかを選択します。 これが良いと言っているのではなく、可能性を示しているだけです。

とにかく、私は先週アムステルダムのミートアップでこのトピックについてプレゼンテーションを行いましたが、エラー処理を正しく行うのを簡単にする機能は、短くするよりも便利であると考えられているようです。

エラーを改善するソリューションは、物事を短くすることよりも、物事を正しくすることを容易にすることに少なくとも同じくらい焦点を合わせる必要があります。

@ALTree errdは、箱から出して「洗練されたエラー回復」を処理します。

@jimmyfrasche ：errdは、遊び場の例とほぼ同じように機能しますが、エラーやパニックを延期者に渡すこともできます。

@jimmyfrasche ：ほとんどの提案は、コードですでに達成できることにはあまり追加されないことに同意します。

@romainmenke ：簡潔さに焦点が当てられすぎていることに同意します。 物事を正しく行うことを容​​易にするために、より大きな焦点を当てるべきです。

@jba ：errdアプローチを使用すると、左側を見るだけでエラーフローと非エラーフローをかなり簡単にスキャンできます（e。で始まるものはすべてエラーまたは延期処理です）。 また、どの戻り値がエラーまたは延期のために処理され、どれが処理されないかをスキャンすることも非常に簡単になります。

@bcmills ：errd自体はスコープの問題を修正しませんが、以前に宣言されたエラー変数などにダウンストリームエラーを渡す必要がないため、エラー処理、AFAICTの問題が大幅に軽減されます。

errdは完全にパニックと回復に依存しているようです。 パフォーマンスが大幅に低下するようです。 このため、全体的な解決策かどうかはわかりません。

@urandom ：
元のコードの場合：

• 延期を使用しません。errdを使用した場合のペナルティは大きく、約100ns *です。
• 慣用的な延期を使用します。実行時間またはエラーは同じオーダーですが、多少遅くなります。
• 延期には適切なエラー処理を使用します。実行時間はほぼ同じです。 延期の数が1より大きい場合、errdはより速くなる可能性があります

その他のオーバーヘッド：

• 現在、クロージャー（w.Close）をDeferに渡すと、DeferCloseまたはDeferFunc APIを使用する場合と比較して約25ns *のオーバーヘッドが追加されます（リリースv0.1.0を参照）。 @rscと話し合った後、APIをシンプルに保ち、後で最適化することを心配するために、それを削除しました。
• インラインエラー文字列をハンドラー（ e.Must(err, msg("oh noes!") ）としてラップするには、Go1.8で約30nsかかります。 ヒント（1.9）では、割り当てはまだありますが、コストを2nsで計測しました。 もちろん、事前に宣言されたエラーメッセージの場合、コストはまだ無視できます。

（*）2016 MacBookProで実行されているすべての番号。

全体として、元のコードがdeferを使用している場合、コストは許容できるようです。 そうでない場合、オースティンは延期のコストを大幅に削減することに取り組んでいるため、時間の経過とともにコストが下がる可能性さえあります。

とにかく、このパッケージのポイントは、我々はポイントで行く2.ケースで最高の言語の追加を構築することができるように感じ、今は有用であろう代替のエラー処理を使用してどのように経験を得ることであるである現在の議論は、それがAの削減にあまり焦点を当てて単純なケースでは数行ですが、得られるものははるかに多く、間違いなく他のポイントがより重要です。

@jimmyfrasche ：

その場合、$ EDITORプラグインは言語を変更せずに機能します

はい、それは私が話の中で主張していることです。 ここで私は、言語を変更する場合、それは「サイドノート」の概念と一致している必要があると主張しています。

@nigeltao

あなたは明らかにそれらを区別することができます。 古い方法は次のようになります。

私は、使用のポイントではなく、宣言のポイントについて話している。

ここで説明する提案の中には、コールサイトで2つを区別しないものもありますが、区別するものもあります。 「値またはエラー」を想定するオプションの1つ（ || 、 try … catch 、 matchを選択した場合、使用するコンパイル時エラーになります。 「値とエラー」関数を使用した構文であり、関数の実装者がそれを定義する必要があります。

宣言の時点では、現在、「値とエラー」と「値またはエラー」を区別する方法はありません。

func Atoi(string) (int, error)

と

func WriteString(Writer, String) (int, error)

戻り値のタイプは同じですが、エラーのセマンティクスが異なります。

@mpvl私は

WithDefault（）の結果を操作するためのトップレベルの関数などの一般的なヘルパーを無視し、単純化のために常にコンテキストを使用し、パフォーマンスに関する決定を無視すると、最小限のベアボーンAPIは以下の操作？

type Handler = func(ctx context.Context, panicing bool, err error) error
Run(context.Context, func(*E), defaults ...Handler) //egregious style but most minimal
type struct E {...}
func (*E) Must(err error, handlers ...Handler)
func (*E) Defer(func() error, handlers ...Handler)

コードを見ると、上記のように定義されていないいくつかの正当な理由がわかりますが、概念をよりよく理解するために、コアセマンティクスを取得しようとしています。 たとえば、 IsSentinelがコアにあるかどうかはわかりません。

@jimmyfrasche

@bcmillsは、これによりスコープが改善されると述べていますが、どうすればよいかわかりません。

主な改善点は、 err変数をスコープ外に保つことです。 これにより、 https：//github.com/golang/go/issues/19727からリンクされているようなバグを回避でき

    res, err := ctxhttp.Get(ctx, c.HTTPClient, dirURL)
    if err != nil {
        return Directory{}, err
    }
    defer res.Body.Close()
    c.addNonce(res.Header)
    if res.StatusCode != http.StatusOK {
        return Directory{}, responseError(res)
    }

    var v struct {
        …
    }
    if json.NewDecoder(res.Body).Decode(&v); err != nil {
        return Directory{}, err
    }

バグは最後のifステートメントで発生します。 Decodeからのエラーは削除されますが、以前のチェックからのerrがまだスコープ内にあったため、明らかではありません。 対照的に、 ::または=?演算子を使用すると、次のように記述されます。

    res := ctxhttp.Get(ctx, c.HTTPClient, dirURL) =? err { return Directory{}, err }
    defer res.Body.Close()
    c.addNonce(res.Header)
    (res.StatusCode == http.StatusOK) =! { return Directory{}, responseError(res) }

    var v struct {
        …
    }
    json.NewDecoder(res.Body).Decode(&v) =? err { return Directory{}, err }

ここで、役立つ2つのスコープの改善があります。

1. 最初のerr （以前のGet呼び出しから）はreturnブロックのスコープ内にあるため、後続のチェックで誤って使用することはできません。
2. Decode errからのDecodeは、nilnessがチェックされるのと同じステートメントで宣言されるため、宣言とチェックの間にスキューはありません。

（1）コンパイル時にエラーを明らかにするには、（1）だけで十分でしたが、（2）明らかな方法でguardステートメントを使用する場合は簡単に回避できます。

@bcmills説明してくれてありがとう

したがって、 res := ctxhttp.Get(ctx, c.HTTPClient, dirURL) =? err { return Directory{}, err }では、 =?マクロは次のように展開されます。

var res *http.Reponse
{
  var err error
  res, err = ctxhttp.Get(ctx, c.HTTPClient, dirURL)
  if err != nil {
    return Directory{}, err 
  }
}

それが正しければ、 :=とは異なるセマンティクスが必要だと言ったときの意味です。

次のような独自の混乱を引き起こすようです。

func f() error {
  var err error
  g() =? err {
    if err != io.EOF {
      return err
    }
  }
  //one could expect that err could be io.EOF here but it will never be so
}

私が何かを誤解していない限り。

うん、それは正しい拡張です。 あなたはそれが:=とは異なるということは正しいです、そしてそれは意図的です。

それはそれ自身の混乱を引き起こすようです

それは本当だ。 それが実際に混乱するかどうかは私にはわかりません。 そうである場合、宣言用のガードステートメントの「：」バリアントを提供できます（「=」バリアントのみを割り当てます）。

（そして今、演算子は=?と=!代わりに=? ?と!と綴られるべきだと私は思います。）

res := ctxhttp.Get(ctx, c.HTTPClient, dirURL) ?: err { return Directory{}, err }

しかし

func f() error {
  var err error
  g() ?= err { (err == io.EOF) ! { return err } }
  // err may be io.EOF here.
}

@mpvl errdに関する私の主な関心事は、ハンドラーインターフェイスに関するものです。これは、コールバックの関数型パイプラインを促進するようですが、コールバック/継続スタイルコード（GoやC ++などの命令型言語と関数型の両方）での経験です。 MLやHaskellのような言語）は、同等のシーケンシャル/命令型スタイルよりも従うのがはるかに難しい場合が多いということです。これは、他のGoイディオムとも一致します。

APIの一部としてHandlerスタイルのチェーンを想定していますか、それともHandlerを検討している他の構文（ Block動作するものなど）の代用ですか？ s？）

@bcmills私はまだ、言語に数十の概念を1行に導入し、1つのものだけで機能する魔法の機能を使用していませんが、最終的に、それらがx, err := f(); if err != nil { return err }を書くためのほんの少し短い方法以上のものである理由を理解しました。

@bcmills @mpvlのやる気を起こさせる例を書き直し=?提案を使用して、厄介なエラー処理を行います。

func writeToGS(ctx context.Context, bucket, dst string, r io.Reader) (err error) {
        client := storage.NewClient(ctx) =? err { return err }
        defer client.Close()

        w := client.Bucket(bucket).Object(dst).NewWriter(ctx)

        defer func() {
                if r := recover(); r != nil { // r is interface{} not error so we can't use it here
                        _ = w.CloseWithError(fmt.Errorf("panic: %v", r))
                        panic(r)
                }

                if err != nil { // could use =! here but I don't see how that simplifies anything
                        _ = w.CloseWithError(err)
                } else {
                        err = w.Close()
                }
        }()

        io.Copy(w, r) =? err { return err } // what about n? does this need to be prefixed by a '_ ='?
        return nil
}

エラー処理の大部分は変更されていません。 =?は2か所でしか使用できませんでした。 そもそも、それは私が見ることができるような利益を実際には提供しませんでした。 2番目の例では、コードが長くなり、 io.Copyが2つのものを返すという事実がわかりにくくなっているため、そこで使用しない方がよいでしょう。

@jimmyfrascheそのコードは例外であり、規則ではありません。 書きやすくするための機能を設計するべきではありません。

また、 recoverもそこにあるべきかどうか疑問に思います。 w.Writeまたはr.Read （またはio.Copy ！）がパニックになっている場合は、終了するのがおそらく最善です。

recoverがなければ、 deferは実際には必要なく、関数の下部は次のようになります。

_ = io.Copy(w, r) =? err { _ = w.CloseWithError(err); return err }
return w.Close()

@jimmyfrasche

// r is interface{} not error so we can't use it here

私の特定の表現（https://github.com/golang/go/issues/21161#issuecomment-319434101）はゼロ値に関するものであり、特にエラーではないことに注意してください。

// what about n? does this need to be prefixed by a '_ ='?

私はそれについてもっと明確にできたかもしれませんが、そうではありません。

その例での@mpvlのrecoverの使用は特に好きではありません。慣用的な制御フローよりもパニックの使用を促進しますが、どちらかといえば、無関係なrecover呼び出しを排除する必要があると思います（ Go 2の標準ライブラリのfmt ）にあるものなど。

そのアプローチでは、そのコードを次のように記述します。

func writeToGS(ctx context.Context, bucket, dst string, r io.Reader) (err error) {
        client := storage.NewClient(ctx) =? err { return err }
        defer client.Close()

        w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
        io.Copy(w, r) =? err {
                w.CloseWithError(err)
                return err
        }
        return w.Close()
}

一方、慣用的な回復では、慣用的なエラー処理をサポートすることを目的とした機能を適用する機会がほとんどないというのは正しいことです。 ただし、リカバリをClose操作から分離すると、IMOのコードがいくらかクリーンになります。

func writeToGS(ctx context.Context, bucket, dst string, r io.Reader) (err error) {
        client := storage.NewClient(ctx) =? err { return err }
        defer client.Close()

        w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
        defer func() {
                if err != nil {
                        _ = w.CloseWithError(err)
                } else {
                        err = w.Close()
                }
        }()
        defer func() {
                recover() =? r {
                        err = fmt.Errorf("panic: %v", r)
                        panic(r)
                }
        }()

        io.Copy(w, r) =? err { return err }
        return nil
}

@jba遅延ハンドラーが再パニックになります。他のコンピューターのプロセスに通知しようとするため、誤って不正なトランザクションをコミットすることはありません（潜在的なエラー状態でも可能であると想定しています）。 それがかなり一般的でない場合は、おそらくそうあるべきです。 読み取り/書き込み/コピーがパニックにならないことに同意しますが、何らかの理由で合理的にパニックになる可能性のある他のコードがそこにあった場合は、最初の場所に戻ります。

@bcmillsの最後のリビジョンは見栄えが良くなります（実際に=?を取り出したとしても）

@jba ：

_ = io.Copy(w, r) =? err { _ = w.CloseWithError(err); return err }
return w.Close()

それはまだ読者のパニックの場合をカバーしていません。 確かにこれはまれなケースですが、非常に重要なケースです。パニックが発生した場合にここでCloseを呼び出すのは非常に悪いことです。

そのコードは例外であり、規則ではありません。 書きやすくするための機能を設計するべきではありません。

@jba ：この場合、私は心から同意しerrd 、保守的なエラー処理を簡単に行える一方で、ルールを緩和するための努力が必要であり、他の方向に少しでも移動するものではないアプローチが必要です。

@jimmyfrasche ：あなたの単純化に関して：あなたは大体正しいです。

• IsSentinelは必須ではなく、便利で一般的です。 少なくとも今のところは落としました。
• 状態のエラーはエラーとは異なるため、APIはこれを削除します。 ただし、理解するために重要ではありません。
• ハンドラーは関数である可能性がありますが、主にパフォーマンス上の理由からインターフェースです。 最適化されていないと、多くの人がパッケージを使用しないことを私は知っています。 （この号のerrdに関する最初のコメントのいくつかを参照してください）
• コンテキストは残念です。 AppEngineはそれを必要としていますが、他にそれほど多くはないと思います。 人々がボークするまで、私はそれに対するサポートを削除しても大丈夫でしょう。

@mpvl私はそれをいくつかのことに絞り込もうとしていたので、それがどのように機能するか、どのように使用するか、そして私が書いたコードにどのように適合するかを想像するのが簡単でした。

@jimmyfrasche ：理解しましたが、APIでそれを行う必要がない場合は問題ありません。 :)

@bcmills ：ハンドラーは、重要度の高い順に、いくつかの目的を果たします。

• エラーをラップする
• エラーを無視するように定義します（明示的にするため。例を参照）
• ログエラー
• エラーメトリック

ここでも重要度の高い順に、これらのスコープを以下で指定する必要があります。

• ブロック
• ライン
• パッケージ

デフォルトのエラーは、エラーがどこかで処理されることを保証しやすくするためのものです。
しかし、私はブロックレベルでしか生きられませんでした。 私はもともとハンドラーの代わりにオプションを備えたAPIを持っていました。 ただし、その結果、APIが遅くなり、さらに不器用になりました。

ここでは、コールバックの問題がそれほどひどいとは思われません。 ユーザーは、エラーが発生した場合に呼び出されるハンドラーをランナーに渡すことでランナーを定義します。 特定のランナーは、エラーが処理されるブロックで明示的に指定されます。 多くの場合、ハンドラーは、インラインで渡されるラップされた文字列リテラルになります。 何が有用で何がそうでないかを確認するために、少し遊んでみます。

ところで、ハンドラーでのログエラーを推奨しない場合は、コンテキストサポートが削除される可能性があります。

@jba ：

また、私は回復がそこにあるべきかどうか疑問に思います。 w.Writeまたはr.Read（またはio.Copy！）がパニックになっている場合は、おそらく終了するのが最善です。

writeToGSは、パニックが発生した場合でも終了します（!!!）。これは、nil以外のエラーでCloseWithErrorを呼び出すことを保証するだけです。 パニックが処理されない場合でも、延期は呼び出されますが、err == nilであるため、CloudStorageでファイルが破損する可能性があります。 ここで行う正しいことは、一時的なエラーでCloseWithErrorを呼び出してから、パニックを続けることです。

Goコードでこのような例をたくさん見つけました。 io.Pipesを処理すると、コードが少し微妙になりすぎることもよくあります。 エラーの処理は、多くの場合、自分で見たほど簡単ではありません。

@bcmills

その例での@mpvlのrecoverの使用は特に好きではありません。これは、慣用的な制御フローよりもパニックの使用を促進します。

パニックの使用を少しでも奨励しようとはしていません。 パニックはCloseWithErrorの直後に再発生するため、制御フローは変更されないことに注意してください。 パニックはパニックのままです。
ただし、ここでrecoverを使用しないのは誤りです。パニックが発生すると、延期がnilエラーで呼び出され、これまでに書き込まれた内容をコミットできることを通知します。

ここでrecoverを使用しない唯一のある程度有効な議論は、任意のReaderであっても、パニックが発生する可能性は非常に低いということです（この例では、理由によりReaderのタイプは不明です:)）。
ただし、本番コードの場合、これは受け入れられないスタンスです。 特に、十分な規模でプログラミングする場合、これはいつか発生するはずです（パニックは、コードのバグ以外の原因で発生する可能性があります）。

ところで、 errdパッケージを使用すると、ユーザーがこれについて考える必要がなくなることに注意してください。 ただし、パニックが発生した場合にエラーを通知するその他のメカニズムは問題ありません。 パニックで延期を呼び出さないことも機能しますが、それ自体に問題があります。

宣言の時点では、現在、「値とエラー」と「値またはエラー」を区別する方法はありません。

@bcmillsああ、なるほど。 別の自転車小屋の缶を開けるには、あなたが言うことができると思います

func Atoi(string) ?int

それ以外の

func Atoi(string) (int, error)

ただし、WriteStringは変更されません。

func WriteString(Writer, String) (int, error)

@bcmills / @ jbaによる=? / =! / :=? / :=!提案は、同様の提案よりも気に入っています。 それはいくつかの素晴らしい特性を持っています：

• 構成可能（ =?ブロック内で=?使用できます）
• 一般（エラータイプに固有ではなく、ゼロ値のみを考慮します）
• 改善されたスコープ
• 延期で動作する可能性があります（上記の1つのバリエーションで）

それはまた、私があまり良くないと思ういくつかの特性を持っています。

構成の巣。 繰り返し使用すると、さらに右にインデントされ続けます。 それ自体は必ずしも悪いことではありませんが、エラーの原因となるエラーを処理する必要がある非常に複雑なエラー処理の状況では、コードが処理するエラーが現在の現状よりもはるかに明確でなくなると思います。 このような状況では、最も外側のエラーに=?を使用し、内側のエラーにif err != nilを使用できますが、これにより、エラー処理が一般的に、または一般的なケースで本当に改善されましたか？ たぶん、一般的なケースを改善することが必要なすべてですが、個人的にはそれが魅力的だとは思いません。

それはその一般性を得るために言語に偽りを導入します。 「ゼロ値ではない」と定義されている偽りは完全に合理的ですが、私の意見では、 if err != nil {は明示的であるため、 if err {よりも優れています。 =? / etcを使おうとする実際のゆがみが見られると思います。 より自然な制御フローを超えて、その偽りにアクセスしようとします。 それは確かに一義的で眉をひそめるでしょうが、それは起こります。 機能の潜在的な悪用は、それ自体が機能に対する反論ではありませんが、考慮すべき点があります。

改善されたスコープ（パラメーターを宣言するバリアントの場合）が優れている場合もありますが、スコープを修正する必要がある場合は、一般的にスコープを修正してください。

「右端の結果のみ」のセマンティクスは理にかなっていますが、私には少し奇妙に思えます。 それは議論というよりは感情です。

この提案は言語に簡潔さを追加しますが、追加の力はありません。 マクロ拡張を行うプリプロセッサとして完全に実装できます。 もちろん、これは望ましくありません。ビルドとフラグメント開発が複雑になり、そのようなプリプロセッサは、型を認識して衛生的である必要があるため、非常に複雑になります。 私は「プリプロセッサを作るだけ」と言って却下しようとはしていません。 私はこれを、この提案が完全に砂糖であることを指摘するためだけに提起します。 Goでは今できなかったことは何もできません。 よりコンパクトに書くことができます。 私は独断的に砂糖に反対していません。 慎重に選択された言語の抽象化には力がありますが、それが砂糖であるという事実は、いわば無実であることが証明されるまで、それが👎と見なされるべきであることを意味します。

演算子のlhsはステートメントですが、ステートメントの非常に限られたサブセットです。 そのサブセットに含める要素はかなり自明ですが、他に何もないとしても、変更に対応するために言語仕様の文法をリファクタリングする必要があります。

のようなものになります

func F() (S, T, error)

func MustF() (S, T) {
  return F() =? err { panic(err) }
}

許可されている？

もしも

defer f.Close() :=? err {
    return err
}

（どういうわけか）同等でなければならないことが許可されます

func theOuterFunc() (err error) {
  //...
  defer func() {
    if err2 := f.Close(); err2 != nil {
      err = err2
    }
  }()
  //...
}

これは非常に問題があり、非常に混乱する状況を引き起こす可能性があり、非常に非Goのような方法で、暗黙的にクロージャを割り当てることのパフォーマンスへの影響を隠していることを無視します。 別の方法は、暗黙のクロージャからreturn返し、 func()からタイプerror値を返すことができないというエラーメッセージを表示することです。鈍い。

ただし、実際には、スコープの修正がわずかに改善されていることを除けば、Goでのエラーの処理で直面する問題は修正されません。 せいぜいif err != nil { return err }と入力するのは厄介で、＃21182で表現したわずかな読みやすさの懸念を法としてです。 2つの最大の問題は

1. エラーを処理する方法を考えています—そしてそれについて言語ができることは何もありません
2. エラーを内省して、状況によっては何をすべきかを判断します。 errorsパッケージからのサポートによる追加の規則は、すべての問題を解決できるわけではありませんが、ここでは大いに役立ちます。

それだけが問題ではなく、多くの人がすぐに他の側面を見つけますが、私が最も時間を費やし、何よりも厄介で厄介な問題だと思います。

もちろん、私が何かを台無しにしたことを検出するためのより良い静的分析は常にありがたいです（そして一般的に、このシナリオだけではありません）。 ソースの分析を容易にする言語の変更と規則により、これらがより有用になることも興味深いでしょう。

私はこれについてたくさん書いたばかりです（たくさん！ごめんなさい！）が、私は提案を却下していません。 メリットはあると思いますが、バーをクリアしたり、重さを引いたりすることには確信が持てません。

@jimmyfrasche

：=の現在の動作が導入されたときのことを覚えています。そのスレッドの多くは、暗黙の「現在のスコープに変数が存在する場合にのみ再利用する」ではなく、再利用する名前に明示的に注釈を付ける方法を求めていました。 「私の経験では、これはすべての微妙な見にくい問題が現れる場所です。

†そのスレッドを見つけることができません誰かがリンクを持っていますか？

Goがリリースされたときに関わっていない限り、別のスレッドを覚えているに違いないと思います。 リリース直前の2009/11/9の仕様には、次のようなものがあります。

通常の変数宣言とは異なり、短い変数宣言は、元々同じタイプの同じブロックで宣言されていて、空白以外の変数の少なくとも1つが新しい場合に、変数を再宣言できます。

以前は：=のある言語を使用していましたが、その再利用ルールがなく、同じものの新しい名前を考えるのは面倒だったので、初めて仕様を読んでそれが素晴らしいルールだと思ったときのことを覚えています。

@mpvl
あなたの元の例のトリッキーさは、より多くの結果だと思います
Goのエラー処理自体よりもそこで使用しているAPI。

これは興味深い例ですが、特に
パニックが発生した場合、通常はファイルを閉じたくないので、
通常の「deferw.Close（）」イディオムは機能しません。

あるときに閉じるを呼び出すことを避ける必要がなかった場合
パニック、そしてあなたはすることができます：

func writeToGS(ctx context.Context, bucket, dst string, r io.Reader) (err error) {
    client, err := storage.NewClient(ctx)
    if err != nil {
        return err
    }
    defer client.Close()

    w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
    defer w.Close()
    _, err = io.Copy(w, r)
    if err != nil {
        w.CloseWithError(err)
    }
    return err
}

Closeを呼び出すようにセマンティクスが変更されたと仮定します
CloseWithErrorを呼び出した後は、何もしません。

もうそんなに悪くはないと思います。

パニックが発生したときにファイルがエラーなしで書き込まれないという要件があっても、対応するのはそれほど難しいことではありません。 たとえば、Closeの前に明示的に呼び出す必要があるFinalize関数を追加します。

    w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
    defer w.Close()
    _, err = io.Copy(w, r)
    return w.Finalize(err)

パニックエラーメッセージを添付することはできませんが、適切なログを記録することで、それをより明確にすることができます。
（Closeメソッドには、recover呼び出しが含まれている可能性もありますが、それが
実際には本当に悪い考えです...）

ただし、この例のパニック回復の側面は、99％以上のエラー処理のケースではパニック回復が行われないため、このコンテキストではやや赤ニシンだと思います。

@rogpeppe ：

パニックエラーメッセージを添付することはできませんが、適切なログを記録することで、それをより明確にすることができます。

それは問題ではないと思います。

提案されたAPIの変更は軽減されますが、問題はまだ完全には解決されていません。 必要なセマンティクスでは、他のコードも適切に動作する必要があります。 以下の例を考えてみましょう。

r, w := io.Pipe()
go func() {
    var err error                // used to intercept downstream errors
    defer func() {
        w.CloseWithError(err)
    }()

    r, err := newReader()
    if err != nil {
        return
    }
    defer func() {
        if errC := r.Close(); errC != nil && err == nil {
            err = errC
        }
    }
    _, err = io.Copy(w, r)
}()
return r

それ自体で、このコードは、エラー処理がトリッキーであるか、少なくとも厄介である可能性があることを示しています（そして、これが他の提案でどのように改善されるのか興味があります）：それはステルスにダウンストリームエラーを変数に渡し、少しもあります正しいエラーが渡されることを保証するための不格好なifステートメント。 どちらも「ビジネスロジック」から気をそらしすぎています。 エラー処理がコードを支配します。 そして、この例はまだパニックを処理していません。

完全を期すために、 errdこの_はパニックを正しく処理し、次のようになります。

r, w := io.Pipe()
go errd.Run(func(e *errd.E) {
    e.Defer(w.CloseWithError)

    r, err := newReader()
    e.Must(err)
    e.Defer(r.Close)

    _, err = io.Copy(w, r)
    e.Must(err)
})
return r

上記のリーダー（ errdを使用していない）がリーダーとしてwriteToGSに渡され、newReaderによって返されたio.Readerがパニックになった場合でも、提案されたAPI修正で誤ったセマンティクスが発生します（正常に終了する可能性があります）パイプがパニックで閉じられた後のGSファイルがnilエラーで表示されます。）

これもポイントを証明します。 Goでの適切なエラー処理について推論するのは簡単ではありません。 errdでコードを書き直すと、コードがどのように見えるかを調べたところ、バグのあるコードがたくさん見つかりました。 errdパッケージの単体テストを作成するときに、適切な慣用的なGoエラー処理を作成することがいかに困難で微妙であるかを実際に学びました。 :)

提案されたAPIの変更に代わる方法は、パニック時に延期をまったく処理しないことです。 これには独自の問題があり、問題を完全に解決することはできず、おそらく元に戻すことはできませんが、いくつかの優れた品質があります。

いずれにせよ、簡潔さに焦点を当てたものではなく、エラー処理の微妙さを軽減する言語の変更が最善でしょう。

@mpvl
Goのエラー処理コードで、別の関数を作成すると問題が解決することがよくあります。 私はあなたのコードをこのようなものの上に書くでしょう：

func something() {
    r, w := io.Pipe()
    go func() {
        err := copyFromNewReader(w)
        w.CloseWithError(err)
    }()
    ...
}

func copyFromNewReader(w io.Writer) error {
    r, err := newReader()
    if err != nil {
        return err
    }
    defer r.Close()
    _, err = io.Copy(w, r)
    return err
}()

r.Closeは有用なエラーを返さないと想定しています。リーダーを最後まで読み、io.EOFのみが発生した場合は、閉じたときにエラーが返されるかどうかはほぼ間違いなく問題ではありません。

私はerrdAPIに熱心ではありません-開始されるゴルーチンに敏感すぎます。 例： https ：
function inはプログラムの正確さに影響を与えるべきではありませんが、errdを使用する場合は影響します。 パニックが抽象化の境界を安全に通過することを期待していますが、Goにはありません。

@mpvl

w.CloseWithError（err）を延期する

ところで、この行は常にCloseWithErrorをnilエラー値で呼び出します。 私はあなたがするつもりだったと思います
書きます：

defer func() { 
   w.CloseWithError(err)
}()

@mpvl

返されるエラーことに注意してくださいClose上の方法io.Readerほとんどない有用ですが（https://github.com/golang/go/issues/20803#issuecomment-312318808でリストを参照してください）。

これは、今日の例を次のように書く必要があることを示唆しています。

r, w := io.Pipe()
go func() (err error) {
    defer func() { w.CloseWithError(err) }()

    r, err := newReader()
    if err != nil {
        return err
    }
    defer r.Close()

    _, err = io.Copy(w, r)
    return err
}()
return r

...少し冗長であることを除けば、これは私には完全に問題ないようです。

パニックが発生した場合にw.CloseWithErrorにnilエラーが渡されるのは事実ですが、プログラム全体はとにかくその時点で終了します。 nilエラーで閉じないことが重要な場合は、単純な名前変更と1行の追加行です。

-go func() (err error) {
-   defer func() { w.CloseWithError(err) }()
+go func() (rerr error) {
+   rerr = errors.New("goroutine exited by panic")
+   defer func() { w.CloseWithError(rerr) }()

@rogpeppe ：確かに、ありがとう。 :)

はい、私はゴルーチンの問題を認識しています。 それは厄介ですが、おそらく獣医のチェックで捕まえるのは難しいことではありません。 とにかく、私はerrdを最終的な解決策としてではなく、エラー処理に最適に対処する方法を経験する方法として見ています。 理想的には、同じ問題を解決する言語の変更がありますが、適切な制限が課せられます。

パニックが抽象化の境界を安全に通過することを期待していますが、Goにはありません。

それは私が期待していることではありません。 この場合、APIが成功しなかったときに成功を報告しないことを期待しています。 最後のコードは、ライターにdeferを使用しないため、正しく処理されます。 しかし、これは非常に微妙です。 この場合、慣用的なものと見なされるため、多くのユーザーはdeferを使用します。

たぶん、獣医のチェックのセットは、延期の問題のある使用法を捕らえることができます。 それでも、元の「慣用的な」コードと最後にリファクタリングされたコードの両方で、他の点では非常に単純なコードである何かの微妙なエラー処理を回避するための多くの調整があります。 回避策のコードは、特定のエラーケースを処理する方法を理解するためのものではなく、生産的な使用に使用できる純粋な脳のサイクルの無駄です。

具体的には、 errdから学ぼうとしているのは、単純に使用した場合にエラー処理がより簡単になるかどうかです。 私が見ることができるものから、多くの複雑さと微妙さが消えます。 そのセマンティクスの側面を新しい言語機能に体系化できるかどうかを確認するのは良いことです。

@jimmyfrasche

それはその一般性を得るために言語に偽りを導入します。

それは非常に良い点です。 偽りに関する通常の問題は、ブール関数を呼び出すのを忘れたり、nilへのポインターを逆参照するのを忘れたりすることから生じます。

演算子をnillable型でのみ機能するように定義することで、後者に対処できます（そして、ほとんど役に立たないため、結果として=!を削除する可能性があります）。

関数型では機能しないように、またはポインター型またはインターフェース型でのみ機能するようにさらに制限することで、前者に対処できます。その場合、変数がブール値ではないことは明らかで

[ MustF ]のようなものは許可されますか？

はい。

[ defer f.Close() :=? err { ]が許可されている場合、それは（どういうわけか）同等でなければなりません
[ defer func() { … }() ]。

必ずしもそうではありません。 独自のセマンティクスを持つことができます（無名関数よりもcall/ccように）。 defer =?を使用するための仕様変更を提案していません（少なくとも文法の変更が必要です）ので、そのような定義がどれほど複雑になるかは正確にはわかりません。 。

2つの最大の問題は[…] 2。エラーを内省して、状況によっては何をすべきかを判断することです。

これは実際にはもっと大きな問題であることに同意しますが、この問題とほぼ直交しているように見えます（これは、定型文とそれに関連するエラーの可能性を減らすことに関するものです）。

（ @ rogpeppe 、 @ davecheney 、 @ dsnet 、 @ crawshaw 、私、および他のいくつかの人は、エラーを検査するためのAPIについてGopherConで素晴らしい議論をしたことを忘れています。その前に、いくつかの良い提案が見られることを願っています。 、しかし私は本当にそれは別の問題の問題だと思います。）

@bcmills ：このコードには2つの問題があります1） @rogpeppeが述べたのと同じ：

それ以外の場合、Closeによって返されるエラーは無視できることが多いことに同意します。 ただし、常にではありません（最初の例を参照）。

私のかなり単純な例（私自身の例を含む）で4つまたは5つの誤った提案が行われたことは少し驚くべきことですが、Goでのエラー処理は簡単ではないとまだ主張しなければならないようです。 :)

@bcmills ：

パニックが発生した場合にw.CloseWithErrorにnilエラーが渡されるのは事実ですが、プログラム全体はとにかくその時点で終了します。

しますか？ そのゴルーチンの延期はまだ呼び出されます。 私が理解している限り、それらは完了するまで実行されます。 この場合、Closeはio.EOFを通知します。

たとえば、 https：//play.golang.org/p/5CFbsAe8zFを参照して

同様に、他のコードは、パニック状態のゴルーチン（例のような）から誤ったio.EOFを受け取り、成功を完了し、パニック状態のゴルーチンがパニックを再開する前にファイルをGSにコミットする場合があります。

次の議論は次のようになるかもしれません：バグのあるコードを書かないでください、しかし：

• 次に、これらのバグの防止を容易にし、
• パニックは、OOMなどの外部要因によって引き起こされる可能性があります。

nilエラーで閉じないことが重要な場合は、単純な名前変更と1行の追加行です。

終了時にio.EOFを通知するために、nilで閉じる必要があるため、機能しません。

nilエラーで閉じないことが重要な場合は、単純な名前変更と1行の追加行です。

終了時にio.EOFを通知するために、nilで閉じる必要があるため、機能しません。

なぜだめですか？ 最後のreturn errは、 rerrをnilます。

@bcmills ：ああ、あなたが今何を意味しているのかわかります。 はい、うまくいくはずです。 ただし、行数については心配していませんが、コードの微妙さについては心配しています。

これは、可変シャドウイングと同じカテゴリの問題であり、発生する可能性はわずかに低くなります（おそらく悪化します）。議論の余地のあるほとんどの可変シャドウイングのバグは、優れた単体テストで発生します。 任意のパニックをテストするのは困難です。

大規模に運用する場合、このようなバグが発生することはほぼ確実です。 私は偏執的かもしれませんが、データの損失や破損につながる可能性がはるかに低いシナリオを見てきました。 通常、これは問題ありませんが、トランザクション処理（gsファイルの書き込みなど）には適していません。

私があなたの提案を別の構文でハイジャックすることを気にしないでください-人々はこのようなものについてどのように感じますか？

return err if f, err := os.Open("..."); err != nil

@SirCmpwnそれは

それは公平ですが、あなたの提案は私にも不快感を与えます-それはユーザーが期待するように訓練された方法とは異なる振る舞いをする不透明な構文（||）を導入します|| 振る舞う。 正しい解決策が何であるかわからない、それをもう少し熟考するでしょう。

@SirCmpwnはい、元の投稿で述べたように、「この提案を書いているのは、主にGoエラー処理を簡素化したい人に、エラーを変更せずに返すだけでなく、エラーの周りにコンテキストを簡単にラップできるようにする方法を考えるように促すためです。 。」 私はできる限り提案を書きましたが、それが採用されることは期待していません。

了解した。

これはもう少し過激ですが、マクロ駆動型のアプローチの方がうまくいくかもしれません。

f = try!(os.Open("..."))

try!は、タプルの最後の値を食べて、nilでない場合はそれを返し、それ以外の場合はタプルの残りの値を返します。

私たちの問題の説明は、

Goでのエラー処理は、冗長で反復的です。 Goのエラー処理の慣用的な形式は、エラー以外の制御フローを確認することをより困難にし、冗長性は、特に初心者にとって魅力的ではありません。 現在まで、この問題に対して提案されたソリューションは、通常、職人による1回限りのエラー処理機能を必要とし、エラー処理の局所性を減らし、複雑さを増しています。 Goの目標の1つは、ライターにエラー処理と回復を検討させることであるため、エラー処理の改善もその目標に基づいて構築する必要があります。

この問題の説明に対処するために、Go2.xでのエラー処理の改善に関する次の目標を提案します。

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

この提案の評価：

f.Close() =? err { return fmt.Errorf(…, err) }

それらの目標によれば、私はそれが目標＃1でうまく成功すると結論付けます。 それが＃2でどのように役立つかはわかりませんが、コンテキストを追加する可能性も低くなりません（私自身の提案は＃2でこの弱点を共有していました）。 ただし、＃3と＃4では実際には成功しません。
1）他の人が言っているように、エラー値のチェックと割り当ては不透明で異常です。 と
2） =?構文も珍しいです。 類似しているが異なる=!構文と組み合わせると、特に混乱します。 人々が彼らの意味に慣れるにはしばらく時間がかかります。 と
3）エラーとともに有効な値を返すことは十分に一般的であるため、新しいソリューションでもそのケースを処理する必要があります。

エラー処理をブロックにするのは良い考えかもしれませんが、他の人が示唆しているように、それはgofmtへの変更と組み合わされています。 私の提案と比較して、それは一般性を改善します。これは、目標＃4に役立ち、親しみやすさは、コンテキストを追加してエラーを返すという一般的なケースの簡潔さを犠牲にして、目標＃3に役立ちます。

要約で私に尋ねた場合、上記のエラー処理の改善目標を満たしている限り、エラー処理の特定のソリューションよりも一般的なソリューションの方が望ましいことに同意したかもしれません。 しかし、この議論を読んでそれについてもっと考えたので、特定の解決策を処理するエラーがより明確で単純になると信じる傾向があります。 Goのエラーは単なる値ですが、エラー処理はプログラミングの重要な部分を構成するため、エラー処理コードを明確かつ簡潔にするための特定の構文が適切であると思われます。 スコーピングや構成可能性などの他の目標と組み合わせると、すでに難しい問題（エラー処理のクリーンな解決策を考え出す）がさらに難しく複雑になるのではないかと思います。

かかわらず、しかし、彼の記事のうち@rscポイントは、と行く2に向けて、どちらの問題声明、目標や構文の提案は、問題が重要であることを証明している経験を報告せずに、事前に可能性があります。 たぶん、さまざまな構文の提案について議論する代わりに、データをサポートするために掘り下げ始めるべきでしょうか？

とはいえ、 @ rscが彼の記事

人間工学が重要であると仮定すれば、これは自明だと思います。 Goコードベースを開き、物事を乾かしたり、言語が対処できる人間工学を改善したりする機会がある場所を探します。現在、エラー処理は明らかに外れ値です。 Toward Go 2のアプローチは、回避策のある問題を無視することを誤って主張している可能性があると思います。この場合、人々はただニヤリと笑って耐えます。

if $val, err := $operation($args); err != nil {
  return err
}

コードよりも定型的なものが多い場合、問題は自明の私見です。

@billyh

f.Close() =? err { return fmt.Errorf(…, err) }の形式は、過度に冗長で混乱しているように感じます。 個人的には、エラー部分がブロックになっているとは思いません。 必然的に、1行ではなく3行に分散されることになります。さらに、エラーを返す前にエラーを変更する以上のことを行う必要があるオフ変更では、現在のif err != nil { ... }使用できます。

=?演算子も少し混乱します。 そこで何が起こっているのかはすぐにはわかりません。

このようなもので：
file := os.Open("/some/file") or raise(err) errors.Wrap(err, "extra context")
または速記：
file := os.Open("/some/file") or raise
と延期：
defer f.Close() or raise(err2) errors.ReplaceIfNil(err, err2)
はもう少し言葉が多く、単語を選択することで最初の混乱を減らすことができます（つまり、 raiseをPythonなどの他の言語の同様のキーワードにすぐに関連付けるか、raiseがエラー/ last-non-を発生させると推測する可能性がありますデフォルト-スタックを呼び出し元に設定します）。

これは、太陽の下で起こりうるすべてのあいまいなエラー処理を解決しようとしない、優れた必須のソリューションでもあります。 はるかに、野生でのエラー処理の最大のチャンクは、上記の性質のものです。 後者については、現在の構文も役立ちます。

編集：
「魔法」を少し減らしたい場合は、前の例も次のようになります。
file, err := os.Open("/some/file") or raise errors.Wrap(err, "extra context")
file, err := os.Open("/some/file") or raise err
defer err2 := f.Close() or errors.ReplaceIfNil(err, err2)
個人的には、前の例の方が、ここでのように分割するのではなく、完全なエラー処理を右に移動するので、より良いと思います。 しかし、これはもっと明確かもしれません。

私たちの問題の説明は、...

私は問題の記述に同意しません。 別の方法を提案したいと思います。

言語の観点からは、エラー処理は存在しません。 Goが提供するのは、事前に宣言されたエラータイプだけです。それでも、本当に新しいものは何も有効にしないため、便宜上です。 エラーは単なる値です。 エラー処理は通常のユーザーコードです。 言語POVからは特別なことは何もありませんし、特別なこともありません。 エラー処理の唯一の問題は、この価値のある美しいシンプルさを絶対に排除しなければならないと考える人がいることです。

Cznicの言う通りに沿って、単なるエラー処理以上のことに役立つソリューションがあると便利です。

エラー処理をより一般的にする1つの方法は、共用体型/合計型とアンラップの観点からエラー処理を考えることです。 SwiftとRustはどちらも？ ！ 構文は、Rustは少し不安定だと思いますが。

合計型を高レベルの概念にしたくない場合は、タプルが実際にはGoの一部ではないように、複数の戻りの一部にすることができますが、それでも複数の戻りを行うことができます。

Swiftに触発された構文の刺し傷：

func Failable() (*Thingie | error) {
    ...
}

guard thingie, err := Failable() else { 
    return wrap(err, "Could not make thingie)
}
// err is not in scope here

これは、次のような他の用途にも使用できます。

guard val := myMap[key] else { val = "default" }

@bcmillsと@jbaによって提案されたソリューション=?は、エラーだけでなく、ゼロ以外の概念です。 この例は正常に機能します。

func Foo()(Bar, Recover){}
bar := Foo() =? recover { log.Println("[Info] Recovered:", recover)}

この提案の主なアイデアは、読みやすくするために、サイドノート、コードの主な目的を分離し、二次的なケースを脇に置くことです。
私にとって、Goコードの読み取りは、場合によっては継続的ではなく、多くの場合、 if err!= nil {return err}でアイデアを止めているので、私たちが読んだ本のように、サイドノートのアイデアは私にとって興味深いようです。主なアイデアを継続的に読んでから、サイドノートを読んでください。 （ @jbaトーク）
非常にまれな状況では、エラーが関数の主な目的であり、おそらく回復中です。 通常、エラーが発生した場合は、コンテキスト、ログ、リターンを追加します。このような場合、サイドノートを使用するとコードが読みやすくなります。
それが最良の構文であるかどうかはわかりません。特に、2番目の部分のブロックは好きではありません。サイドノートは小さくする必要があり、行は十分である必要があります。

bar := Foo() =? recover: log.Println("[Info] Recovered:", recover)

@billyh

1. 他の人が言っているように、エラー値のチェックと割り当ては不透明で珍しいものです。 と

もっと具体的に言ってください。「不透明で珍しい」はひどく主観的です。 提案が混乱するだろうと思うコードの例をいくつか挙げていただけますか？

1. =？ 構文も珍しいです。 […]

それが機能のIMOです。 誰かが異常なオペレーターを見た場合、正確であるかどうかわからないことを単に想定するのではなく、それが何をしているのかを調べる傾向があるのではないかと思います。

1. エラーとともに有効な値を返すことは十分に一般的であるため、新しいソリューションでもそのケースを処理する必要があります。

します？

提案を注意深く読んでください。 =?は、 Block評価する前に割り当てを実行するため、その場合にも使用できます。

n := r.Read(buf) =? err {
  if err == io.EOF {
    […]
  }
  return err
}

また、 @ nigeltaoが指摘したように、既存の 'n、err：= r.Read（buf） `パターンをいつでも使用できます。 一般的なケースのスコープと定型文を支援する機能を追加しても、それをまれなケースにも使用する必要があることを意味するわけではありません。

たぶん、さまざまな構文の提案について議論する代わりに、データをサポートするために掘り下げ始めるべきでしょうか？

Ianが元の投稿でリンクした多数の問題（およびそれらの例）を参照してください。
https://github.com/golang/go/wiki/ExperienceReports#error-handlingも参照して

これらのレポートから具体的な洞察を得た場合は、それを共有してください。

@urandom

個人的には、エラー部分がブロックになっているとは思いません。 必然的に、それはそれを1行ではなく3行に広げることになります。

ブロックの目的は2つあります。

1. エラーを生成する式とそのハンドラーの間に明確な視覚的および文法的な区切りを提供し、
2. より広い範囲のエラー処理を可能にするため（元の投稿で@ianlancetaylorが述べた目標ごとに）。

3行対1は、言語の変更でさえありません。行数が最大の懸念事項である場合は、 gofmt変更するだけで対処できます。

file, err := os.Open("/some/file") or raise errors.Wrap(err, "extra context")
file, err := os.Open("/some/file") or raise err

すでにreturnとpanicます; それらの上にraiseを追加すると、ゲインが少なすぎるために関数を終了する方法が多すぎるように見えます。

defer err2 := f.Close() or errors.ReplaceIfNil(err, err2)

errors.ReplaceIfNil(err, err2)には、非常に珍しい参照渡しのセマンティクスが必要です。
代わりに、ポインタでerr渡すことができます。

defer err2 := f.Close() or errors.ReplaceIfNil(&err, err2)

しかし、それでも私には非常に奇妙に思えます。 orトークンは、式、ステートメント、またはその他のものを構成しますか？ （より具体的な提案が役立つでしょう。）

@carlmjohnson

guard … elseステートメントの具体的な構文とセマンティクスは何でしょうか？ 私には、トークンと可変位置が入れ替わった=?または::よく似ているように見えます。 （繰り返しになりますが、より具体的な提案が役立ちます：あなたが念頭に置いている実際の構文とセマンティクスは何ですか？）

@bcmills
架空のReplaceIfNilは単純です。

func ReplaceIfNil(original, replacement error) error {
   if original == nil {
       return replacement
   }
   return original
}

それについては何も珍しいことはありません。 たぶん名前...

orは二項演算子であり、左側のオペランドはIdentifierListまたはPrimaryExprのいずれかです。 前者の場合、右端の識別子になります。 次に、左側のオペランドがデフォルト値でない場合に、右側のオペランドを実行できるようにします。

そのため、後で式の値を取得する関数Resultの最後のパラメーターを除いて、デフォルト値を返す魔法を実行するために、後で別のトークンが必要になりました。
IIRC、少し前に、面倒なデフォルト値の初期化の代わりに、言語に「...」などを追加するという別の提案がありました。 そのため、全体は次のようになります。

f, err := os.Open("/some/file") or return ..., errors.Wrap(err, "more context")

ブロックに関しては、より広いハンドリングが可能になることを理解しています。 この提案の範囲が、仮想の80％をカバーするのではなく、考えられるすべてのシナリオに対応することであるかどうかは、個人的にはわかりません。 そして、私は個人的に、結果が何行かかるかが重要であると信じています（=？のようなあいまいなトークンを使用する場合、それが私の最大の関心事であるとは決して言いませんでしたが、実際には読みやすさ、またはその欠如です）。 この新しい提案が一般的なケースで複数の行にまたがる場合、私は個人的に次のようなものよりもその利点を理解していません。

if f, err := os.Open("/some/file"); err != nil {
     return errors.Wrap(err, "more context")
}

• 上記で定義された変数がifスコープ外で利用可能になる場合。
  そして、それでも、これらのエラー処理ブロックの視覚的なノイズのために、そのようなステートメントが2つしかない関数は読みにくくなります。 そして、それは、外出先でのエラー処理について議論するときに人々が抱く不満の1つです。

@urandom

orは二項演算子であり、左側のオペランドはIdentifierListまたはPrimaryExprのいずれかです。 […]次に、左側のオペランドがデフォルト値でない場合に、右側のオペランドを実行できるようにします。

Goの二項演算子は式であり、ステートメントではないため、 orを二項演算子にすると多くの疑問が生じます。 （より大きな式の一部としてのorのセマンティクスは何ですか？また、 :=投稿した例でそのジャイブはどのようになりますか？）

それが実際にステートメントであると仮定すると、右側のオペランドは何ですか？ それが式である場合、そのタイプは何ですか、そしてraiseは他のコンテキストで式として使用できますか？ それがステートメントである場合、 raise以外の場合、そのセマンティクスは何ですか？ または、 or raiseを本質的に単一のステートメントにすることを提案していますか（たとえば、 ::または=?代わりの構文としてor raise =? ）？

書けますか

defer f.Close() or raise(err2) errors.ReplaceIfNil(err, err2) or raise(err3) Transform(err3)

？

書けますか

f(r.Read(buf) or raise err)

？

defer f.Close() or raise(err2) errors.ReplaceIfNil(err, err2) or raise(err3) Transform(err3)

いいえ、2番目のraiseため、これは無効になります。 それがなかった場合は、変換チェーン全体が実行され、最終結果が呼び出し元に返されるはずです。 全体としてそのようなセマンティクスはおそらく必要ありませんが、次のように書くことができます。

defer f.Close() or raise(err2) Transform(errors.ReplaceIfNil(err, err2)

f(r.Read(buf) or raise err)

私の元のコメントを想定すると、左側の最後の値をとる、または取るので、デフォルト値の場合、最終的な式は結果リストの残りの部分に評価されます。 はい、これは有効なはずです。 この場合、 r.Readがエラーを返すと、そのエラーが呼び出し元に返されます。 それ以外の場合、 nはf渡されます

編集：

用語に混乱しない限り、 orは二項演算子だと思います。そのオペランドは同じタイプである必要があります（ただし、左側のオペランドがリストである場合は、少し魔法のようになります。その場合、それは上記のリストの最後の要素を取ります）。 raiseは、そのオペランドを取り、そのオペランドの値を最後の戻り引数の値として使用して関数から戻る単項演算子であり、前の引数にはデフォルト値があります。 次に、関数（別名return ..., errから戻る目的で、スタンドアロンステートメントでraiseを技術的に使用できます。

これは理想的なケースですが、 or raiseは、ブロックではなく単純なステートメントも受け入れる限り、 =?構文の代替としても問題ありません。あまり冗長ではない方法でユースケースの大部分をカバーします。 または、式を受け入れるdeferのような文法を使用することもできます。 これは、次のようなケースの大部分をカバーします。

f := os.Open("/some/file") or raise(err) errors.Wrap(err, "with context")

複雑なケース：

f := os.Open or raise(err) func() {
     if err == io.EOF {
         […]
     }
  return err
}()

私の提案についてもう少し考えて、私は共用体/合計型について少し落としています。 私が提案している構文は

guard [ ASSIGNMENT || EXPRESSION ] else { [ BLOCK ] }

式の場合、式が評価され、結果がブール式のtrueまたは他の式の空白値と等しくない場合、BLOCKが実行されます。 割り当てでは、最後に割り当てられた値が!= true / != nilに対して評価されます。 ガードステートメントに続いて、行われたすべての割り当てがスコープ内になります（新しいブロックスコープは作成されません[おそらく最後の変数を除いて？]）。

Swiftでは、 guardステートメントのBLOCKには、 return 、 break 、 continue 、またはthrowいずれかが含まれている必要があります。 私はそれが好きかどうかは決めていません。 読者はguardという単語から何が続くかを知っているので、それはある程度の価値を追加するようです。

guardがそのコミュニティによって高く評価されているかどうかを言うのに十分なほどSwiftをフォローしている人はいますか？

例：

guard f, err := os.Open("/some/file") else { return errors.Wrap(err, "could not open:") }

guard data, err := ioutil.ReadAll(f) else { return errors.Wrap(err, "could not read:") }

var obj interface{}

guard err = json.Unmarshal(data, &obj) else { return errors.Wrap(err, "could not unmarshal:") }

guard m, _ := obj.(map[string]interface{}) else { return errors.New("unexpected data format") }

guard val, _ := m["key"] else { return errors.New("missing key") }

私見では、誰もが一度にここであまりにも広範囲の問題について話し合っていますが、実際の最も一般的なパターンは「そのままのエラーを返す」です。 では、次のようなsmthで最も問題に取り組みませんか。

code, err ?= fn()

これは、関数がerr！= nil？で戻る必要があることを意味します。

：=演算子の場合、導入できますか？：=

code, err ?:= fn()

コンパイラは変数「err」を同じ名前のerr戻り値に渡す必要があるため、？：=の状況はシャドウイングのために悪化しているようです。

間違ったコードを単に短くするのではなく、正しいコードを簡単に記述できるようにすることに焦点を当てている人がいることに、私は実際にかなり興奮しています。

いくつかのメモ：

エラーモデルに関するマイクロソフトのMidoriの設計者の1人からの興味深い「経験レポート」 。

このドキュメントとSwiftのいくつかのアイデアは、Go2に美しく適用できると思います。

新しい再保存されたthrowsキーワードを導入すると、関数は次のように定義できます。

func Get() []byte throws {
  if (...) {
    raise errors.New("oops")
  }

  return []byte{...}
}

別の非スロー関数からこの関数を呼び出そうとすると、未処理のスロー可能エラーが原因でコンパイルエラーが発生します。
代わりに、一般的なケースであることに誰もが同意するエラーを伝播するか、それを処理できる必要があります。

func ScrapeDate() time.Time throws {
  body := Get() // compilation error, unhandled throwable
  body := try Get() // we've been explicit about potential throwable

  // ...
}

メソッドが失敗しないことがわかっている場合、またはテストで、swiftと同様にtry!導入できます。

func GetWillNotFail() time.Time {
  body := Get() // compilation error, throwable not handled
  body := try Get() // compilation error, throwable can not be propagated, because `GetWillNotFail` is not annotated with throws
  body := try! Get() // works, but will panic on throws != nil

  // ...
}

ただし、これらについてはよくわかりません（swiftと同様）：

func main() {
  // 1:
  do {
    fmt.Printf("%v", try ScrapeDate())
  } catch err { // err contains caught throwable
    // ...
  }

  // 2:
  do {
    fmt.Printf("%v", try ScrapeDate())
  } catch err.(type) { // similar to a switch statement
    case error:
      // ...
    case io.EOF
      // ...
  }
}

ps1。 複数の戻り値func ReadRune() (ch Rune, size int) throws { ... }
ps2。 return try Get()またはreturn try! Get()戻ることができます
ps3。 buffer.NewBuffer(try Get())やbuffer.NewBuffer(try! Get())ような呼び出しをチェーンできるようになりました
ps4。 注釈についてよくわからない（ errors.Wrap(err, "context")を書く簡単な方法）
ps5。 これらは実際には例外です
ps6。 最大のメリットは、無視された例外のコンパイル時エラーです。

あなたが書いた提案は、すべての悪いものと一緒にみどりリンクに正確に記述されています
それの側面...そして「投げる」からの1つの明白な結果は「人々
嫌い」。ほとんどの場合、毎回「スロー」と書く必要があるのはなぜですか。
機能？

ところで、エラーを強制的にチェックして無視しないという意図は、
エラー以外のタイプにも適用されます。
一般化された形式（例：gcc __attribute __（（warn_unused_result）））。

演算子の形式については、短い形式または
このようなキーワードフォーム：

？= fn（）またはfn（）をチェックします-呼び出し元にエラーを伝播します
！= fn（）またはnofail fn（）-エラー時にパニック

12:15時土、2017年8月26日には、nvartolomei [email protected]
書きました：

いくつかのメモ：

面白い体験レポート
http://joeduffyblog.com/2016/02/07/the-error-model/から
エラーモデルに関するMicrosoftのMidoriの設計者。

このドキュメントとSwiftからいくつかのアイデアがあると思います
https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/ErrorHandling.html
Go2に美しく適用できます。

新しい再保存されたthrowsキーワードを導入すると、関数は次のように定義できます。

func Get（）[] byte throws {
もしも （...） {
エラーを発生させます。New（ "oops"）
}

[] byte {...}を返します
}

この関数を別の非スロー関数から呼び出そうとすると、
未処理のスロー可能なエラーが原因で、コンパイルエラーが発生します。
代わりに、エラーを伝播できるはずです。これは誰もが同意するものです。
一般的なケース、またはそれを処理します。

func ScrapeDate（）time.Time throws {
body：= Get（）//コンパイルエラー、未処理のスロー可能
body：= try Get（）//スロー可能な可能性について明示しました

//..。
}

メソッドが失敗しないことがわかっている場合、またはテストでは、次のことができます。
紹介してみてください！ スイフトに似ています。

func GetWillNotFail（）time.Time {
body：= Get（）//コンパイルエラー、スロー可能は処理されません
body：= try Get（）//コンパイルエラー。 GetWillNotFailはthrowsの注釈が付いていないため、throwableを伝播できません。
body：=試してみてください！ Get（）//動作しますが、スローするとパニックになります！= nil

//..。
}

ただし、これらについてはよくわかりません（swiftと同様）：

func main（）{
// 1：
行う {
fmt.Printf（ "％v"、ScrapeDate（）を試してください）
} catch err {// errにはキャッチされたthrowableが含まれています
//..。
}

// 2：
行う {
fmt.Printf（ "％v"、ScrapeDate（）を試してください）
} catch err。（type）{// switchステートメントに似ています
ケースエラー：
//..。
ケースio.EOF
//..。
}
}

ps1。 複数の戻り値funcReadRune（）（ch Rune、size int）throws {
...}
ps2。 return try Get（）またはreturn tryで戻ることができます！ 取得する（）
ps3。 これで、buffer.NewBuffer（try Get（））やbuffer.NewBuffer（try！
取得する（））
ps4。 注釈についてよくわからない

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

@jbaと@bcmillsによって提案された演算子は、「??」と綴る方が適切ですが、非常に優れたアイデアだと思います。 「=？」の代わりに IMO。

この例を見てください：

func doStuff() (int,error) {
    x, err := f() 
    if err != nil {
        return 0, wrapError("f failed", err)
    }

    y, err := g(x)
    if err != nil {
        return 0, wrapError("g failed", err)
    }

    return y, nil
}

func doStuff2() (int,error) {
    x := f()  ?? (err error) { return 0, wrapError("f failed", err) }
    y := g(x) ?? (err error) { return 0, wrapError("g failed", err) }
    return y, nil
}

doStuff2は、次の理由により、かなり読みやすく、すばやく読むことができると思います。

1. 垂直方向のスペースの無駄が少ない
2. 左側の幸せな道をすばやく読みやすい
3. 右側のエラー状態をすばやく読み取るのは簡単です
4. 関数のローカル名前空間を汚染するerr変数はありません

私には、この提案だけでは不完全に見え、魔法が多すぎます。 ??演算子はどのように定義されますか？ 「nilでない場合、最後の戻り値をキャプチャします」？ 「メソッドタイプに一致する場合、最後のエラー値をキャプチャしますか？」

位置とタイプに基づいて戻り値を処理するための新しい演算子を追加することは、ハックのように見えます。

2017年8月29日、午前13時03分0300、ミカエル・グスタフ[email protected] 、書きました：

@jbaと@bcmillsによって提案された演算子は、「??」と綴る方が適切ですが、非常に優れたアイデアだと思います。 「=？」の代わりに IMO。
この例を見てください：
func doStuff（）（int、error）{
x、err：= f（）
err！= nil {の場合
0を返し、wrapError（ "f failed"、err）
}

   y, err := g(x)
   if err != nil {
           return 0, wrapError("g failed", err)
   }

   return y, nil

}

func doStuff2（）（int、error）{
x：= f（）?? （エラーエラー）{return 0、wrapError（ "f failed"、err）}
y：= g（x）?? （エラーエラー）{return 0、wrapError（ "g failed"、err）}
y、nilを返す
}
doStuff2は、次の理由により、かなり読みやすく、すばやく読むことができると思います。

1. 垂直方向のスペースの無駄が少ない
2. 左側の幸せな道をすばやく読みやすい
3. 右側のエラー状態をすばやく読み取るのは簡単です
4. 関数のローカル名前空間を汚染するerr変数はありません

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

@nvartolomei

??演算子はどのように定義されますか？

https://github.com/golang/go/issues/21161#issuecomment-319434101およびhttps://github.com/golang/go/issues/21161#issuecomment-320758279を参照してください。

@bcmillsは静止スレッドを復活させることを推奨しているので、他の言語からのクリブを検討する場合、ステートメント修飾子はこれらすべてに合理的な解決策を提供するようです。 @slvmndの例をとるには、ステートメント修飾子を使用してやり直します。

func doStuff() (int, err) {
        x, err := f()
        return 0, wrapError("f failed", err)     if err != nil

    y, err := g(x)
        return 0, wrapError("g failed", err)     if err != nil

        return y, nil
}

ステートメントとエラーチェックを1行で行うほど簡潔ではありませんが、かなりよく読みます。 （if式で：=形式の割り当てを許可しないことをお勧めします。そうしないと、文法が明確であっても、スコープの問題によって人々が混乱する可能性があります）「if」の否定バージョンとして「unless」を許可するのは少しです構文糖衣ですが、読むとうまく機能し、検討する価値があります。

ただし、ここでPerlからクリブすることはお勧めしません。 （Basic Plus 2は問題ありません）そのように、ステートメント修飾子をループします。これは、便利な場合もありますが、かなり複雑な問題の別のセットをもたらします。

短いバージョン：
err！= nilの場合に戻る
その場合もサポートする必要があります。

このような構文では、疑問が生じます-非戻りステートメントも必要です
次のような「if」ステートメントでサポートされます。
func（args）if条件

おそらくアフターアクションを発明する代わりに-シングルを導入する価値がある場合
の場合の行？

err！= nilreturnの場合
err！= nilが0を返す場合、wrapError（ "failed"、err）
err！= nil do_smth（）の場合

特別な形式の構文よりもはるかに自然なようですよね？ たぶん
構文解析に多くの苦痛をもたらします：/

しかし...それはすべて小さな調整であり、エラーに対する特別なlangサポートではありません
取り扱い/伝播。

16:14時月、2017年9月18日には、dsugalski [email protected]は書きました：

@bcmills https://github.com/bcmillsが復活することを推奨しているので、
静止スレッド、他の言語からのクリブを検討する場合は、
ステートメント修飾子はすべての人に合理的な解決策を提供するようです
これ。 @slvmnd https://github.com/slvmndの例をとるには、次のようにやり直します。
ステートメント修飾子：

func doStuff（）（int、err）{
x、err：= f（）
err！= nilの場合、0を返し、wrapError（ "f failed"、err）

  y, err := g(x)
    return 0, wrapError("g failed", err)     if err != nil

    return y, nil

}

ステートメントとエラーチェックを1つにまとめるほど簡潔ではありません
行ですが、それはかなりよく読みます。 （：=形式のを禁止することをお勧めします
if式での割り当て、そうでない場合、スコープの問題が発生する可能性があります
文法がはっきりしていても人を混乱させる）
「if」の否定バージョンは少し構文糖衣ですが、
読んで、検討する価値があります。

ただし、ここでPerlからクリブすることはお勧めしません。 （Basic Plus2は
細かい）そのようにループステートメント修飾子がありますが、
便利です。かなり複雑な問題の別のセットを持ち込んでください。

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

@dsugalskiの提案についてみると、

純粋なテキストからどれだけの視覚的な区別を期待するのが合理的かはわかりません。 ある時点で、それをテキストエディタのIDEまたはコードカラーリングレイヤーにパントする方が適切だと思われます。

しかし、テキストベースの視覚的な区別のために、私がこれを恥ずかしいほど昔に使い始めたときに私たちが持っていたフォーマット標準は、IF / UNLESSステートメント修飾子を右寄せする必要があり、それによって十分に目立つようになりました。 （ただし、VT-220端末では、ウィンドウサイズがより柔軟なエディターよりも、適用が容易で、おそらく視覚的に区別できる標準が付与されています）

少なくとも私にとっては、ステートメント修飾子のケースは簡単に区別でき、現在のif-blockスキームよりも読みやすくなっています。 もちろん、これは他の人には当てはまらないかもしれません。私は英語のテキストを読むのと同じ方法でソースコードを読むので、既存の快適なパターンにマッピングされますが、誰もがこれを行うわけではありません。

return 0, wrapError("f failed", err) if err != nilはif err != nil { return 0, wrapError("f failed", err) }と書くことができます

if err != nil return 0, wrapError("f failed", err)も同じように書くことができます。

たぶん、ここで必要なのは、gofmtがifを3行に拡張するのではなく、1行に1行で書いたままにすることだけですか？

私を襲う別の可能性があります。 使い捨てのGoコードをすばやく書き込もうとしたときに経験する多くの摩擦は、すべての呼び出しでエラーチェックを行う必要があるため、呼び出しを適切にネストできないためです。

たとえば、最初にhttp.NewRequestの結果を一時変数に割り当ててから、その上でDoを呼び出さずに、新しい要求オブジェクトでhttp.Client.Doを呼び出すことはできません。

私たちは許可できるかどうか疑問に思います：

f(y())

yが(T, error)タプルを返しても機能します。 yがエラーを返すと、コンパイラは式の評価を中止し、そのエラーをfから返す可能性があります。 fがエラーを返さない場合は、エラーが返される可能性があります。

それから私はすることができました：

n, err := http.DefaultClient.Do(http.NewRequest("DELETE", "/foo", nil))

NewRequestまたはDoのいずれかが失敗した場合、エラー結果はnil以外になります。

ただし、これには1つの重大な問題があります。つまり、fが2つの引数、または可変個引数を受け入れる場合、上記の式はすでに有効です。 また、これを行うための正確なルールはかなり複雑になる可能性があります。

したがって、一般的に、私はそれが好きではないと思います（このスレッドの他の提案にも熱心ではありません）が、とにかく検討のためにアイデアを捨てると思いました。

@rogpeppeまたはあなただけ使用することができますjson.NewEncoderを

@gbbrはい、悪い例です。

より良い例はhttp.Requestかもしれません。 それを使用するようにコメントを変更しました。

わお。 多くのアイデアがコードの可読性をさらに悪化させています。
私はアプローチで大丈夫です

if val, err := DoMethod(); err != nil {
   // val is accessible only here
   // some code
}

本当に厄介なのは、返された変数のスコープです。
この場合、 valを使用する必要がありますが、範囲はifです。
したがって、 elseを使用する必要がありますが、リンターはそれに反対します（そして私も）。

val, err := DoMethod()
if err != nil {
   // some code
}
// some code with val

ifブロック外の変数にアクセスできると便利です。

if val, err := DoMethod(); err != nil {
   // some code
}
// some code with val

@dmbreakerこれが、基本的にSwiftのガード句の目的です。 何らかの条件を通過した場合、現在のスコープ内の変数を割り当てます。 私の以前のコメントを参照し

私はGoでのエラー処理を単純化することに全力を注いでいますが（個人的にはそれほど気にしませんが）、これにより、他の点では単純で非常に読みやすい言語に少し魔法がかかると思います。

@gbbr
ここで言及している「これ」とは何ですか？ 物事を進める方法については、かなりの数の異なる提案があります。

おそらく2つの部分からなる解決策ですか？

tryを「戻りタプルの右端の値をはがします。その型のゼロ値でない場合は、他の値をゼロに設定して、この関数の右端の値として返します」と定義します。 これは一般的なケースになります

 a := try ErrorableFunction(b)

連鎖を可能にします

 a := try ErrorableFunction(try SomeOther(b, c))

（オプションで、効率を上げるために、ゼロ以外ではなくゼロ以外にします。）エラー関数がゼロ以外/ゼロ以外を返す場合、関数は「値で中止」します。 try 'ed関数の右端の値は、呼び出し元の関数の右端の値に割り当て可能である必要があります。そうしないと、コンパイル時の型チェックエラーになります。 （したがって、これはerrorのみを処理するようにハードコーディングされていませんが、おそらくコミュニティは他の「賢い」コードの使用を推奨しないはずです。）

次に、次のいずれかのdeferのようなキーワードでtryreturnsをキャッチできるようにします。

catch func(e error) {
    // whatever this function returns will be returned instead
}

または、もっと大雑把に言えば、Goがすでにどのように機能しているかにもっと一致しています。

defer func() {
    if err := catch(); err != nil {
        set_catch(ErrorWrapper{a, "while posting request to server"})
    }
}()

catch場合、関数のパラメーターは返される値と正確に一致する必要があります。 複数の関数が提供されている場合、値はそれらすべてを逆の順序で通過します。 もちろん、正しいタイプの関数に解決される値を入れることができます。 deferベースの例の場合、1つのdefer関数がset_catch呼び出すと、次の延期関数はそれをcatch()値として取得します。 （プロセスでnilに戻すのに十分愚かである場合は、紛らわしい戻り値が出力されます。そうしないでください。）set_catchに渡される値は、返される型に割り当て可能である必要があります。 どちらの場合も、これは宣言ではなくステートメントであり、ステートメントの実行後にのみコードに適用されるという点で、これがdeferように機能することを期待しています。

私は単純さの観点から延期ベースのソリューションを好む傾向があります（基本的に新しい概念は導入されていません。新しいものではなく、2番目のタイプのrecover()です）が、パフォーマンスの問題がある可能性があることを認めます。 個別のcatchキーワードを使用すると、通常のリターンが発生したときに完全にスキップしやすくなるため、効率が向上する可能性があります。最大の効率を実現したい場合は、スコープまたは関数ごとに1つだけがアクティブになるように、スコープに関連付けます。 、これはほぼゼロコストだと思います。 （おそらく、ソースコードファイル名と行番号もcatch関数から返される必要がありますか？コンパイル時にそれを行うのは安価であり、人々が今フルスタックトレースを要求する理由のいくつかをかわすでしょう。）

どちらも、繰り返しのエラー処理を関数内の1つの場所で効果的に処理できるようにし、エラー処理をライブラリ関数として簡単に提供できるようにします。これは、上記のrscのコメントによると、現在のケースの最悪の側面の1つです。 エラー処理の面倒さは、正しい処理ではなく「returnerr」を助長する傾向があります。 私はそれと自分自身で多くの苦労をしていることを知っています。

@thejerfこの提案に関するIanのポイントの一部は、関数がコンテキストを追加したり、返されたエラーを操作したりすることを思いとどまらせることなく、エラーの定型文に対処する方法を探ることです。

エラー処理をtryとcatch分けると、その目標に反するように見えますが、プログラムが通常追加する詳細の種類によって異なります。

少なくとも、より現実的な例でどのように機能するかを確認したいと思います。

私の提案の全体的なポイントは、コンテキストを追加したり、エラーを操作したりできるようにすることです。これは、そのコンテキストを何度も繰り返すことを含むここでのほとんどの提案よりもプログラム的に正しいと考える方法であり、それ自体が追加のコンテキストを入れたいという欲求を妨げます。 。

元の例を書き直すには、

func Chdir(dir string) error {
    if e := syscall.Chdir(dir); e != nil {
        return &PathError{"chdir", dir, e}
    }
    return nil
}

として出てきます

func Chdir(dir string) error {
    catch func(e error) {
        return &PathError{"chdir", dir, e}
    }

    try syscall.Chdir(dir)
    return nil
}

ただし、この例は、実際にはこれらの提案のいずれにも取るに足らないものであり、この場合は、元の関数をそのままにしておくと思います。

個人的には、そもそも元のChdir関数が問題だとは思っていません。 私はこれを特に調整して、1つのエラー関数ではなく、長時間繰り返されるエラー処理によって関数にノイズが発生する場合に対処しています。 また、考えられるすべてのユースケースで文字通り異なることを行う関数がある場合、正しい答えはおそらく、すでに得たものを書き続けることだと思います。 しかし、それが一般的なケースであったとしても、そもそも苦情はないという理由で、ほとんどの人にとってこれは非常にまれなケースだと思います。 エラーをチェックするノイズは、関数内で「ほぼ同じこと」を何度も繰り返したいという理由だけで重要です。

私はまた、人々が望んでいるもののほとんどが満たされるだろうと思います

func SomethingBigger(dir string) (interface{}, error) {
     catch func (e error, filename string, lineno int) {
         return PackageSpecificError{e, filename, lineno, dir}
     }

     x := try Something()

     if x == true {
         try SomethingElse()
     } else {
         a, b = try AThirdThing()
     }

     return whatever, nil
}

小さすぎて気にしないという理由で単一のifステートメントの見栄えを良くしようとする問題を取り除き、エラーが返されるたびに本当にユニークなことをしている関数の問題を取り除きます。 ：これは実際にはかなりまれなケースであり、B：その場合、ボイラープレートのオーバーヘッドは、固有の処理コードの複雑さに対して実際にはそれほど重要ではありません。おそらく、問題は解決策のあるものに減らすことができます。

私も本当に見たいです

func packageSpecificHandler(f string) func (err error, filename string, lineno int) {
    return func (err error, filename string, lineno int) {
        return &PackageSpecificError{"In function " + f, err, filename, lineno}
    }
}

 func SomethingBigger(dir string) (interface{}, error) {
     catch packageSpecificHandler("SomethingBigger")

     ...
 }

または、それが機能する場合は、同等のものが可能です。

そして、ページ上のすべての提案の中で...これはまだGoのように見えませんか？ 現在のGoよりもGoのように見えます。

正直なところ、私の専門的なエンジニアリング経験のほとんどはPHP（私は知っています）でしたが、Goの主な魅力は常に読みやすさでした。 私はPHPのいくつかの側面を楽しんでいますが、私が最も軽蔑しているのは、「最終的な」「抽象的な」「静的な」ナンセンスであり、1つのことを行うコードに過度に複雑な概念を適用することです。

この提案を見ると、ある部分を見て、ダブルテイクを実行し、そのコードの部分が何を言っているのか、または何をしているのかを本当に「考え」なければならないという感覚にすぐに逆戻りしました。 私はこのコードが読みやすく、実際に言語に追加されるとは思いません。 私の最初の本能は左側を見ることであり、これは常にnil返すと思います。 ただし、この変更により、コードの動作を判断するために、左右を見る必要があります。これは、より多くの時間を読んで、より多くのメンタルモデルを意味します。

ただし、これはGoでのエラー処理を改善する余地がないことを意味するものではありません。

申し訳ありませんが、このスレッド全体を（まだ）読んでいません（非常に長いです）が、人々が別の構文を投げているのを見るので、私の考えを共有したいと思います：

a, err := helloWorld(); err? {
  return fmt.Errorf("helloWorld failed with %s", err)
}

これを無効にする上記の何かを見逃していないことを願っています。 私はいつかすべてのコメントを通り抜けることを約束します:)

型変換のセマンティックの混乱を避けるために、演算子はerror型でのみ許可される必要があると私は信じています。

興味深い、 @ buchanae 、しかしそれは私たちをはるかに乗り越えますか？

if a, err := helloWorld(); err != nil {
  return fmt.Errorf("helloWorld failed with %s", err)
}

aをエスケープできるのは確かですが、現在の状態では、スコープはthenブロックとelseブロックになります。

@ object88そうです、変化は微妙で、美的で、主観的です。 個人的には、このトピックに関してGo 2に求めているのは、読みやすさの微妙な変更だけです。

個人的には、行がif始まっておらず、 !=nil必要としないため、読みやすくなっています。 変数は、（ほとんど？）他の行にある左端にあります。

aの範囲の素晴らしい点、私はそれを考慮していませんでした。

この文法の他の可能性を考えると、これは可能であるように思われます。

err := helloWorld(); err? {
  return fmt.Errorf("error: %s", err)
}

そしておそらく

helloWorld()? {
  return fmt.Errorf("hello world failed")
}

多分それがバラバラになるところです。

たぶん、エラーを返すことはGoのすべての関数呼び出しの一部であるはずなので、次のことを想像できます。
`` `
a：= helloWorld（）; え？ {{
fmt.Errorf（ "helloWorld failed：％s"、err）を返します
}

実際の例外処理はどうですか？ つまり、試して、キャッチして、最終的には多くの現代語のように？

いいえ、コードが暗黙的で不明確になります（ただし、実際には少し短くなります）

7時27分に木、2017年11月23日には、Kamyar Miremadi [email protected]
書きました：

実際の例外処理はどうですか？ つまり、試して、キャッチして、最後に
代わりに多くの現代語のように？

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

@mpvlのWriteToGCSの例のアップスレッドに戻って、コミット/ロールバックパターンは、Goのエラー処理の大幅な変更を保証するほど一般的ではないことを（再度）提案したいと思います。 関数（遊び場リンク）でパターンをキャプチャするのは難しくありません：

func runWithCommit(f, commit func() error, rollback func(error)) (err error) {
    defer func() {
        if r := recover(); r != nil {
            rollback(fmt.Errorf("panic: %v", r))
            panic(r)
        }
    }()
    if err := f(); err != nil {
        rollback(err)
        return err
    }
    return commit()
}

次に、例を次のように記述できます。

func writeToGCS(ctx context.Context, bucket, dst string, r io.Reader) error {
    client, err := storage.NewClient(ctx)
    if err != nil {
        return err
    }
    defer client.Close()

    w := client.Bucket(bucket).Object(dst).NewWriter(ctx)
    return runWithCommit(
        func() error { _, err := io.Copy(w, r); return err },
        func() error { return w.Close() },
        func(err error) { _ = w.CloseWithError(err) })
}

私はより簡単な解決策を提案します：

func someFunc() error {
    ^err := someAction()
    ....
}

複数の複数の関数が返される場合：

func someFunc() error {
    result, ^err := someAction()
    ....
}

そして、複数の戻り引数の場合：

func someFunc() (result Result, err error) {
    var result Result
    params, ^err := someAction()
    ....
}

^記号は、パラメーターがnilでない場合に戻ることを意味します。
基本的に「エラーが発生した場合はスタックを上に移動する」

この方法の欠点はありますか？

@gladkikhartem
エラーが返される前に、どのようにエラーを変更しますか？

@urandom
エラーのラップは重要なアクションであり、私の意見では明示的に実行する必要があります。
Goコードは読みやすさに関するものであり、魔法ではありません。
エラーラッピングをより明確にしたいと思います

しかし同時に、多くの情報を運ばず、スペースをとるだけのコードを取り除きたいと思います。

if err != nil {
    return err
}

それは囲碁の決まり文句のようなものです-あなたはそれを読みたくない、あなたはただそれをスキップしたいのです。

この議論でこれまでに見たのは、次の組み合わせです。

1. 構文の冗長性を減らす
2. コンテキストを追加してエラーを改善する

これは、両方の側面に言及している@ianlancetaylorによる元の問題の説明と

1.構文の冗長性の削減

@gladkikhartemのアイデアは、編集/拡張されてからここで報告する元の形式でも

 result, ^ := someAction()

funcのコンテキストでは：

func getOddResult() (int, error) {
    result, ^ := someResult()
    if result % 2 == 0 {
          return result + 1, nil
    }
    return result, nil
}

この短い構文（または@gladkikhartemによってerr^提案された形式）は、問題の構文の冗長性の部分に対処します（1）。

2.エラーコンテキスト

2番目の部分では、コンテキストを追加することで、今のところ完全に忘れることができます。後で、特別なcontextErrorタイプが使用されている場合、各エラーにスタックトレースを自動的に追加することを提案します。 このような新しいネイティブエラータイプは、完全または短いスタックトレース（ GO_CONTEXT_ERROR=full想像してください）を備え、 errorインターフェイスと互換性があり、最上位の呼び出しスタックから少なくとも関数とファイル名を抽出する可能性を提供します。エントリ。

contextErrorを使用する場合、どういうわけかGoは、エラーが作成された正確なポイントに呼び出しスタックトレースをアタッチする必要があります。

再びfuncの例で：

func getOddResult() (int, contextError) {
    result, ^ := someResult() // here a 'contextError' is created; if the error received from 'someResult()' is also a `contextError`, the two are nested
    if result % 2 == 0 {
          return result + 1, nil
    }
    return result, nil
}

タイプのみがerrorからcontextErrorに変更されました。これは、次のように定義できます。

type contextError interface {
    error
    Stack() []StackEntry
    Cause() contextError
}

（このStack()がhttps://golang.org/pkg/runtime/debug/#Stackとどのように異なるかに注意してください。これは、バイト以外のバージョンのgoroutine呼び出しスタックがここにあることを望んでいるためです）

Cause()メソッドは、ネストの結果としてnilまたは前のcontextErrorを返します。

私は、このようなスタックを持ち歩くことの潜在的なメモリへの影響をよく知っているので、1つまたは少数のエントリしか含まないデフォルトの短いスタックを持つ可能性を示唆しました。 開発者は通常、開発/デバッグバージョンで完全なstracktraceを有効にし、それ以外の場合はデフォルト（短いスタックトレース）のままにします。

先行技術：

• https://godoc.org/github.com/pkg/errors （このパッケージを詳しく知らないか、モデル化する必要があることを示唆していますが、最も使用されている/既知のパッケージの1つです）

ただ考えるための食べ物。

@gladkikhartem @ gdm85

あなたはこの提案の要点を見逃したと思います。 イアンの元の投稿によると：

エラーを無視することはすでに簡単です（おそらく簡単すぎます）（＃20803を参照）。 エラー処理に関する既存の提案の多くは、変更せずにエラーを返すのを容易にします（たとえば、＃16225、＃18721、＃21146、＃21155）。 追加情報を使用してエラーを簡単に返すことができるものはほとんどありません。

変更せずにエラーを返すことはしばしば間違っており、通常は少なくとも役に立たない。 注意深いエラー処理を奨励したいと思います。「変更されていないリターン」のユースケースのみに対処すると、インセンティブが間違った方向にバイアスされます。

@bcmillsコンテキスト（スタックトレースの形式）が追加されている場合、エラーは追加情報とともに返されます。 「レコード挿入中のエラー」などの人間が読めるメッセージを添付することは、「注意深いエラー処理」と見なされますか？ コールスタックのどの時点でそのようなメッセージを追加する必要があるかを決定するにはどうすればよいですか（各関数、トップ/ボトムなど）？ これらはすべて、コーディングエラー処理の改善に関する一般的な質問です。

「returnunmodified」は、デフォルトで「return unmodified with stacktrace」を使用して上記で説明したように打ち消すことができ、（リアクティブスタイルで）必要に応じて人間が読めるメッセージを追加します。 このような人間が読めるメッセージを追加する方法は指定していませんが、いくつかのアイデアについては、 pkg/errorsでラッピングがどのように機能するかを確認できます。

「変更せずにエラーを返すことはしばしば間違っています」：したがって、私は怠惰なユースケースのアップグレードパスを提案します。これは、現在有害であると指摘されているのと同じユースケースです。

@bcmills
私は＃20803に100％同意します。エラーは常に処理するか、明示的に無視する必要があります（そして、なぜこれが以前に行われなかったのかわかりません...）
はい、私は提案のポイントに対処しませんでした、そして私はそうする必要はありません。 意図は結果と一致しないため、背後にある意図ではなく、提案された実際の解決策に関心があります。 そして私が見るとき|| そのような|| 提案されているもの-それは私を本当に悲しくさせます。

エラーコードやエラーメッセージなどの情報をエラーに埋め込むのが簡単で透過的である場合（慎重なエラー処理を奨励する必要はありません）、人々はそれを自分で行います。
たとえば、エラーをエイリアスにします。 あらゆる種類のものを返し、キャストせずに関数の外で使用することができます。 人生をとても楽にしてくれるでしょう。

Goがエラーを処理するように私に思い出させるのは好きですが、デザインが私に疑わしいことをするように勧めるときは嫌いです。

@ gdm85
エラーにスタックトレースを自動的に追加するのはひどい考えです。Javaスタックトレースを見てください。
エラーを自分でラップすると、何が問題になっているのかをナビゲートして理解するのがはるかに簡単になります。 それがそれを包むことの全体的なポイントです。

@gladkikhartem私は、「自動ラッピング」の形式がナビゲートし、何が悪いのかを理解するのを助けるのにはるかに悪いだろうということに同意し

Goのベストプラクティス（多かれ少なかれ標準的である可能性があります）の理解を深めることと、そのような定義が現在の状況からの改善に向けた提案を行うための鍵になると思うので、両方にお願いします。

@gladkikhartemこの提案はすでにif err != nil { return err }単純化することに関するいくつかの異なる提案がすでにあり、それらはその特定のケースを改善するだけの構文を議論する場所です。 ありがとう。

@ianlancetaylor
議論を邪魔にならないように動かしてしまったらごめんなさい。

エラーにコンテキスト情報を追加する場合は、次の構文を使用することをお勧めします。
（そして、コンテキスト抽出を容易にするために、1つの関数に対して1つのエラータイプのみを使用するように人々に強制します）

type MyError struct {
    Type int
    Message string
    Context string
    Err error
}

func VeryLongFunc() error {
    var err MyError
    err.Context = "general function context"


   result, ^err.Err := someAction() {
       err.Type = PermissionError
       err.Message = fmt.SPrintf("some action has no right to access file %v: ", file)
   }

    // in case we need to make a cleanup after error

   result, ^err.Err := someAction() {
       err.Type = PermissionError
       err.Message = fmt.SPrintf("some action has no right to access file %v: ", file)
       file.Close()
   }

   // another variant with different symbol and return statement

   result, ?err.Err := someAction() {
       err.Type = PermissionError
       err.Message = fmt.SPrintf("some action has no right to access file %v: ", file)
       return err
   }

   // using original approach

   result, err.Err := someAction()
   if err != nil {
       err.Type = PermissionError
       err.Message = fmt.SPrintf("some action has no right to access file %v: ", file)
       return err
   }
}

func main() {
    err := VeryLongFunc()
    if err != nil {
        e := err.(MyError)
        log.Print(e.Error(), " in ", e.Dir)
    }
}

^記号は、エラーパラメータを示し、関数定義と「someAction（）{}」のエラー処理を区別するために使用されます。
エラーが変更されずに返された場合は、{}を省略できます

「注意深いエラー処理」をより適切に定義するために、私自身の招待に返信するためのリソースをさらに追加します。

• https://groups.google.com/forum/#!topic/golang -nuts / dkcNS4ieIpQ
• https://blog.golang.org/errors-are-values
• https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully

現在のアプローチと同じくらい退屈ですが、ステートメントが機能する可能性がある場合は1行ですが、他のアプローチよりも混乱が少ないと思います。 多分？

blah, err := doSomething()
if err != nil: return err

...あるいは...

blah, err := doSomething()
if err != nil: return &BlahError{"Something",err}

誰かがすでにこれを提起したかもしれませんが、たくさんの投稿があり、私はそれらの多くを読みましたが、すべてではありません。 とはいえ、個人的には、暗黙的であるよりも明示的である方が良いと思います。

私は鉄道指向プログラミングのファンでした。アイデアはElixirのwithステートメントから来ています。
elseブロックは、 e == nil短絡すると実行されます。

これが、擬似コードを先に置いた私の提案です。

func Chdir(dir string) (e error) {
    with e == nil {
            e = syscall.Chdir(dir)
            e, val := foo()
            val = val + 1
            // something else
       } else {
           printf("e is not nil")
           return
       }
       return nil
}

@ardhitamaこれは、「With」が「Try」ステートメントのようなものであり、「Else」が「C​​atch」のようなものであることを除いて、
JavaやC＃のような例外処理を実装してみませんか？
プログラマーがその関数で例外を処理したくない場合は、その関数の結果として例外を返します。 それでも、プログラマーが望まない場合に例外を処理するように強制する方法はなく、多くの場合、本当に必要はありませんが、ここで得られるのは、コードを醜くするif err！= nilステートメントです。読み取り不能（ノイズが多い）。 そもそも他のプログラミング言語でTryCatchFinallyステートメントが発明されたのはそれが理由ではないでしょうか。

ですから、Go Authorsが頑固にならないように「やってみて」ください！ 次のバージョンでは、「TryCatchFinally」ステートメントを導入するだけです。 ありがとう。

@KamyarM
Goには例外がないため、goに例外処理を導入することはできません。
Goでtry {} catch {}を導入することは、Cでtry {} catch {}を導入することに似それはまったく間違っています。

@ianlancetaylor
Goのエラー処理をまったく変更せずに、このようなgofmtツールを1行のエラー処理に変更するのはどうでしょうか。

err := syscall.Chdir(dir)
    if err != nil {return &PathError{"chdir", dir, err}}
err = syscall.Chdir(dir2)
    if err != nil {return err}

下位互換性があり、現在のプロジェクトに適用できます

例外は装飾されたgotoステートメントであり、コールスタックをコールグラフに変換します。最も深刻な非学術プロジェクトがその使用を禁止または制限するのには十分な理由があります。 ステートフルオブジェクトは、制御を任意にスタックに転送してから命令の実行を再開するメソッドを呼び出します...それは悪い考えのように聞こえます。

@KamyarM本質的にはそうですが、実際にはそうではありません。 私の意見では、ここでは明示的であり、Goのイディオムを破っていないためです。

どうして？

1. withステートメント内の式は、新しい変数を宣言できないため、ブロック変数から評価することを明示的に示しています。
2. with内のステートメントは、 tryおよびcatchブロック内のように動作します。 実際、最悪のシナリオでwithの状態を評価する必要がある次の各命令では、速度が低下します。
3. 設計上、ハンドラーは常にローカルになるため、過剰なifを削除し、例外ハンドラーを作成しないようにします（ withの式とelseブロック）。
4. throwため、スタックを巻き戻す必要はありません

ps。 私が間違っている場合は私を訂正してください。

@ardhitama
KamyarMは、 withステートメントがtry catchと同じくらい醜く見え、通常のコードフローにインデントレベルを導入するという意味で正しいです。
各エラーを個別に修正するという元の提案のアイデアについても言及していません。 一緒にグループ文というそれだけのtryでキャッチ、または他の方法でエレガントに仕事に行くのではありません。

@gladkikhartem
はい、したがって、私は代わりに「鉄道指向プログラミング」を採用することを提案し、明示性を削除しないようにします。 問題を攻撃するのは別の角度です。他のソリューションでは、コンパイラーにif err != nilを自動的に書き込ませないことで問題を解決したいと考えています。

withは、エラー処理だけでなく、他の制御フローにも役立ちます。

@gladkikhartem
Try Catch Finallyブロックは美しいと思います。 If err!=nil ...は実際には醜いコードです。

Goは単なるプログラミング言語です。 他にもたくさんの言語があります。 私は、囲碁コミュニティの多くがそれを自分たちの宗教のように見ており、間違いを変えたり認めたりすることを受け入れていないことを知りました。 これは間違っています。

@gladkikhartem

Goの作者がそれをGo ++またはGo＃またはGoJavaと呼んで、そこにTry Catch Finallyを紹介しても大丈夫です;）

@KamyarM

不必要な変更を回避することは、エンジニアリングの取り組みにとって必要であり、重要です。 人々がこの文脈で変化を言うとき、彼らは実際には_より良い方向への変化_を意味し、それはその意図された結論への前提を導く_議論_で効果的に伝えます。

_ただあなたの心を開いてください！_魅力は説得力がありません。 皮肉なことに、それはほとんどのプログラマーが古くて不格好だと見なしていることを_新しく改善された_と言おうとします。

Goコミュニティが以前の過ちについて話し合う多くの提案や議論もあります。 しかし、Goは単なるプログラミング言語であるとあなたが言うとき、私はあなたに同意します。 それは囲碁のウェブサイトや他の場所でそう言っています、そして私はそれを確認した何人かの人々にも話しました。

私は、囲碁コミュニティの多くがそれを自分たちの宗教のように見ており、間違いを変えたり認めたりすることを受け入れていないことを知りました。

Goは学術研究に基づいています。 個人的な意見は関係ありません。

MicrosoftのC＃コンパイラの主要な開発者でさえ、_exceptions_はエラーを管理するための悪い方法であると公に認めていますが、Go / Rustモデルをより良い代替手段として賞賛しています： http ：

確かに、Goのエラーモデルを改善する余地はありますが、いくつかの疑わしい利点と引き換えに非常に複雑になるだけなので、例外のようなソリューションを採用することはできません。

@ Dr-ひどい記事をありがとう。

しかし、GoLangをアカデミック言語として言及しているところはどこにも見つかりませんでした。

ところで、私のポイントを明確にするために、この例では

func Execute() error {
    err := Operation1()
    if err!=nil{
        return err
    }

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

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

    err = Operation4()
    return err
}

次のようにC＃で例外処理を実装するのと似ています。

         public void Execute()
        {

            try
            {
                Operation1();
            }
            catch (Exception)
            {
                throw;
            }
            try
            {
                Operation2();
            }
            catch (Exception)
            {
                throw;
            }
            try
            {
                Operation3();
            }
            catch (Exception)
            {
                throw;
            }
            try
            {
                Operation4();
            }
            catch (Exception)
            {
                throw;
            }
        }

それはC＃での例外処理のひどい方法ではありませんか？ 私の答えはイエスです、私はあなたのことを知りません！ Goでは他に選択肢はありません。 それはそのひどい選択または高速道路です。 これがGOの状況であり、私には選択の余地がありません。

ちなみに、あなたが共有した記事でも述べたように、どの言語でも追加の構文を必要とせずにGoのようなエラー処理を実装できるため、Goは実際には革新的なエラー処理方法を実装していません。 エラー処理の方法がないため、エラー処理にIfステートメントを使用するように制限されています。

ところで、GOには推奨されていないPanic, Recover , Deferがあり、これはTry Catch Finallyに似ていますが、私の個人的な意見では、 Try Catch Finally構文は、例外処理のよりクリーンで整理された方法です。

@ Dr-ひどい

また、これをチェックしてください：
https://github.com/manucorporat/try

@KamyarM 、彼はGoが学術言語であるとは言いませんでした、彼はそれが学術研究に基づいていると言いました。 Goに関する記事もありませんでしたが、Goが採用したエラー処理パラダイムを調査しています。

manucorporat/tryが適切であることがわかった場合は、コードで使用してください。 ただし、言語自体にtry/catchを追加するコスト（パフォーマンス、言語の複雑さなど）は、トレードオフの価値がありません。

@KamyarM
あなたの例は正確ではありません。 の代替

    err := Operation1()
    if err!=nil {
        return err
    }
    err = Operation2()
    if err!=nil{
        return err
    }
    err = Operation3()
    if err!=nil{
        return err
    }
    return Operation4()

になります

            Operation1();
            Operation2();
            Operation3();
            Operation4();

この例では、例外処理の方がはるかに優れているようです。 理論的には良いはずですが、実際には
エンドポイントで発生したエラーごとに、正確なエラーメッセージを返信する必要があります。
Goのアプリケーション全体は通常50％のエラー処理です。

         err := Operation1()
    if err!=nil {
        log.Print("input error", err)
                fmt.Fprintf(w,"invalid input")
        w.WriteHeader(http.StatusBadRequest)
        return
    }
    err = Operation2()
    if err!=nil{
        log.Print("controller error", err)
                fmt.Fprintf(w,"operation has no meaning in this context")
        w.WriteHeader(http.StatusBadRequest)
        return
    }
    err = Operation3()
    if err!=nil{
        log.Print("database error", err)
                fmt.Fprintf(w,"unable to access database, try again later")
        w.WriteHeader(http.StatusServiceUnavailable)
        return
    }

そして、もし人々がキャッチを試みるような強力なツールを持っているなら、私は彼らが注意深いエラー処理を支持してそれを使いすぎると100％確信しています。

アカデミアが言及されているのは興味深いですが、囲碁は実際の経験から学んだ教訓の集まりです。 誤ったエラーメッセージを返す不正なAPIを作成することが目標である場合は、例外処理が最適です。

ただし、リクエストに不正な形式のJSON request bodyが含まれている場合、 invalid HTTP headerエラーは発生しません。例外処理は、使用するC ++およびC＃APIでそれを実現する魔法の発射と忘れのボタンです。彼ら。

APIカバレッジが大きい場合、意味のあるエラー処理を実現するのに十分なエラーコンテキストを提供することは不可能です。 これは、優れたアプリケーションはGoで50％のエラー処理であり、エラーを処理するために非ローカル制御転送を必要とする言語では90％である必要があるためです。

@gladkikhartem

あなたが言及した別の方法は、C＃でコードを書く正しい方法です。 これはわずか4行のコードであり、正常な実行パスを示しています。 それらのif err!=nilノイズはありません。 例外が発生した場合、それらの例外を処理する関数はTry Catch Finallyを使用してそれを処理できます（同じ関数自体、または呼び出し元の呼び出し元または呼び出し元、または呼び出し元の呼び出し元の呼び出し元の呼び出し元である可能性があります） ...または、アプリケーションで未処理のすべてのエラーを処理するイベントハンドラー。プログラマーにはさまざまな選択肢があります。）

err := Operation1()
    if err!=nil {
        log.Print("input error", err)
                fmt.Fprintf(w,"invalid input")
        w.WriteHeader(http.StatusBadRequest)
        return
    }
    err = Operation2()
    if err!=nil{
        log.Print("controller error", err)
                fmt.Fprintf(w,"operation has no meaning in this context")
        w.WriteHeader(http.StatusBadRequest)
        return
    }
    err = Operation3()
    if err!=nil{
        log.Print("database error", err)
                fmt.Fprintf(w,"unable to access database, try again later")
        w.WriteHeader(http.StatusServiceUnavailable)
        return
    }

シンプルに見えますが、それはトリッキーなものです。 おそらく、システムエラー、ユーザーエラー（最善の意図を持っていない可能性のあるユーザーに内部状態をリークすることなく）、およびHTTPコードを含むカスタムエラータイプをまとめることができます。

func Chdir(dir string) error {
    if e := syscall.Chdir(dir); e != nil {
        return &PathError{"chdir", dir, e}
    }
    return nil
}

しかし、それを試してみてください

func Chdir(dir string) error {
    return  syscall.Chdir(dir) ? &PathError{"chdir", dir, err}:nil;
}

func Chdir(dir string) error {
    return  syscall.Chdir(dir) ? &PathError{"chdir", dir, err};
}



md5-9bcd2745464e8d9597cba6d80c3dcf40



```go
func Chdir(dir string) error {
    n , _ := syscall.Chdir(dir):
               // something to do
               fmt.Println(n)
}

それらのすべてには、読者にとって物事を単純化しない、ある種の明白でない魔法が含まれています。 前の2つの例では、 errは、ある種の疑似キーワードまたは自発的に発生する変数になります。 後者の2つの例では、 :演算子が何をしているのかがまったくわかりません。エラーは自動的に返されますか？ オペレーターのRHSは単一のステートメントですか、それともブロックですか？

FWIW、 return newPathErr("chdir", dir, syscall.Chdir(dir))を実行できるようにラッパー関数を記述し、3番目のパラメーターがnilの場合は自動的にnilエラーを返します。 :-)

IMO、私が見た中で最高の提案は＃21732に「簡素化エラーゴーでの取り扱い」と「追加のコンテキスト情報とエラーを返す」@mrkaspaからあるの目標を達成するには：

a, b, err? := f1()

これに拡張します：

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

そして私はこれでそれをパニックにさせることができます：

a, b, err! := f1()

これに拡張します：

if err != nil {
   panic(errors.Wrap(err, "failed"))
}

これにより、下位互換性が維持され、goでのエラー処理のすべての問題点が修正されます。

これは、ゼロ以外の値やエラーを返すbufio関数のようなケースには対応していませんが、他の戻り値が気になる場合は、明示的なエラー処理を行っても問題ないと思います。 そしてもちろん、エラー以外の戻り値は、そのタイプに適切なnil値である必要があります。

？ 修飾子は、関数と！のボイラープレートエラーの受け渡しを減らします。 修飾子は、assertが一部のメイン関数などの他の言語で使用される場所でも同じことを行います。

このソリューションには、非常にシンプルで、やりすぎないという利点がありますが、この提案書に記載されている要件を満たしていると思います。

あなたが持っている場合...

func foo() (int, int, error) {
    a, b, err? := f1()
    return a, b, nil
}
func bar() (int, error) {
    a, b, err? := foo()
    return a+b, nil
}

fooで問題が発生した場合、 barの呼び出しサイトで、エラーは意味を追加せずに同じテキストで二重にラップされます。 少なくとも、私は提案のerrors.Wrap部分に反対します。

しかし、さらに拡大すると、これの期待される結果は何ですか？

func baz() (a, b int, err error) {
  a = 1
  b = 2
  a, b, err? = f1()
  return

aとbはnil値に再割り当てされますか？ もしそうなら、それは魔法であり、避けるべきだと私は感じています。 彼らは以前に割り当てられた値を実行しますか？ （私は名前付きの戻り値を自分で気にしませんが、それでもこの提案の目的のために考慮する必要があります。）

@ dup2Xええ、言語を削除しましょう、それはもっとそうあるべきです

@ object88エラーが発生した場合、他のすべてが

ラッピングに関しては、デフォルトのメッセージは何も役に立たないと思います。 エラーを連鎖させるだけでも問題ありません。 例外に内部例外がある場合のように。 ライブラリの奥深くでエラーをデバッグするのに非常に便利です。

敬意を表して、私は同意しません、@ creker。 このシナリオの例は、nil以外のエラーの場合でも、nil以外の戻り値のGo stdlibにあり、実際には、 bufio.Reader構造体のいくつかの関数のように機能します。 私たちGoプログラマーは、すべてのエラーをチェック/処理することを積極的に奨励されています。 nil以外の戻り値とエラーを取得するよりも、エラーを無視する方がひどい感じがします。 引用する場合、nilsを返し、エラーをチェックしないと、無効な値を操作している可能性があります。

しかし、それはさておき、これをもう少し調べてみましょう。 ?演算子のセマンティクスは何でしょうか？ errorインターフェースを実装する型にのみ適用できますか？ 他のタイプに適用したり、引数を返したりできますか？ エラーを実装しない型に適用できる場合、nil以外の値/ポインターによってトリガーされますか？ ?演算子を複数の戻り値に適用できますか、それともコンパイラエラーですか？

@erwbgy
有用なものを添付せずにエラーを返したい場合は、コンパイラにすべての未処理のエラーを「if err！= nilreturn ...」として処理するように指示する方がはるかに簡単です。次に例を示します。

func doStuff() error {
    doAnotherStuff() // returns error
}

func doStuff() error {
    res := doAnotherStuff() // returns string, error
}

そして、追加の狂気の必要はありませんか？ この場合の記号。

@ object88
ここに示されているエラーラッピングの提案のほとんどを実際のコードに適用しようとしましたが、1つの大きな問題に直面しました。コードが密集しすぎて、判読できなくなります。
コードの高さを優先して、コードの幅を犠牲にするだけです。
err！= nilの場合、エラーを通常でラッピングすると、実際には読みやすくするためにコードを拡散できるため、エラーラッピングのために何も変更する必要はないと思います。

@ object88

サイトを作成する場合、nilsを返し、エラーをチェックしないと、無効な値で操作している可能性があります。

しかし、それは、nilのパニックのような明白で見つけやすいエラーを生成します。 エラー時に意味のある値を返す必要がある場合は、明示的にそれを行い、その場合に使用できる値を正確に文書化する必要があります。 エラー時にたまたま変数に含まれていたランダムなものを返すだけでは危険であり、微妙なエラーにつながります。 繰り返しますが、それからは何も得られません。

@gladkikhartem if err！= nilの問題は、実際のロジックが完全に失われることです。コードが成功したパスで何をするのかを理解し、エラー処理を気にしない場合は、積極的に検索する必要があります。 。 実際のコードが数行あり、それ以外はすべてエラーチェックであるCコードをたくさん読んでいるようなものになります。 人々は、そのすべてをラップして関数の最後に移動するマクロに頼ることさえあります。

適切に記述されたコードでロジックがどのように密集しすぎるのかわかりません。 それは論理です。 コードのすべての行には、気になる実際のコードが含まれています。 あなたが望まないのは、ボイラープレートの線と線を通過することです。 コメントを使用し、それが役立つ場合はコードをブロックに分割します。 しかし、それは言語ではなく実際のコードの問題のように聞こえます。

再フォーマットしない場合、これは遊び場で機能します。

a, b, err := Frob("one string"); if err != nil { return a, b, fmt.Errorf("couldn't frob: %v", err) }
// continue doing stuff with a and b

したがって、元の提案、および上記の他の多くの提案は、これらの100文字の明確な省略構文を考え出し、gofmtが改行の追加と3行にわたるブロックの再フォーマットを主張するのを止めようとしているようです。

それで、gofmtを変更して、複数行のブロックを主張するのをやめ、上の行から始めて、それをより短く、より明確にする方法を考え出すことを想像してみましょう。

セミコロンの前の部分（割り当て）を変更して、69文字を削減する必要はないと思います。 これらのうち、49はreturnステートメント、返される値、およびエラーラッピングであり、その構文を変更することにはあまり価値がありません（たとえば、returnステートメントをオプションにすることで、ユーザーを混乱させます）。

そのため、アンダースコアがコードのチャンクを表す; if err != nil { _ }省略形を見つけることができます。 nilの比較が多少見えなくなったとしても、わかりやすくするために、省略形には明示的にerrを含める必要があると思います。そのため、 ; if _ != nil { _ }省略形を考え出す必要があります。

少しの間、1つの文字を使用することを想像してみてください。 そのキャラクターが何であれ、プレースホルダーとして§を選択します。 その場合、コードの行は次のようになります。

a, b, err := Frob("one string") § err return a, b, fmt.Errorf("couldn't frob: %v", err)

既存の代入構文や戻り構文を変更したり、目に見えない魔法を発生させたりせずに、それよりもはるかに優れた方法がわかりません。 （errとnilを比較しているという事実がすぐにはわからないという点で、まだいくつかの魔法があります。）

これは88文字で、100文字の行に合計12文字を節約できます。

だから私の質問は：それは本当にやりがいがあるのか​​？

編集：私のポイントは、人々がGoのif err != nilブロックを見て、「そのがらくたを取り除くことができればいいのに」と言うとき、彼らが話していることの80〜90％はあなたが本質的に持っているものだと思いますエラーを処理するために行うこと_。 Goの構文によって引き起こされる実際のオーバーヘッドは最小限です。

@lpar 、あなたは私が上で適用したのとほとんど同じ論理に従っているので、当然私はあなたの推論に同意します。 しかし、私はあなたがすべてのエラーを右に置くことの視覚的な魅力を軽視していると思います：

a, b := Frob("one string")  § err { return ... }

単なる文字数の削減を超える要因で読みやすくなります。

@lparほとんど役に立たないfmt.Errorfを削除し、returnを特別な構文に変更し、呼び出しスタックをエラーに導入して、実際のコンテキストを持ち、単なる栄光の文字列ではない場合は、さらに多くの文字を節約できます。 それはあなたにこのようなものを残すでしょう

a, b, err? := Frob("one string")

私にとってのGoエラーの問題は、常にコンテキストの欠如でした。 文字列を返したり折り返したりすることは、エラーが実際に発生した場所を特定するのにまったく役立ちません。 そのため、たとえばgithub.com/pkg/errorsは私にとって必須になりました。 このようなエラーでは、Goエラー処理の単純さの利点と、コンテキストを完全にキャプチャして障害の正確な場所を見つけることができる例外の利点が得られます。

また、例をそのまま使用しても、エラー処理が右側にあるという事実は、読みやすさを大幅に向上させます。 コードの実際の意味を理解するために、ボイラープレートの数行をスキップする必要がなくなりました。 エラー処理の重要性についてあなたが望むことを言うことができますが、それを理解するためにコードを読むとき、私はエラーを気にしません。 私に必要なのは成功した道です。 そして、私がエラーを必要とするとき、私はそれらを具体的に探します。 エラーは、その性質上、例外的なケースであり、可能な限りスペースをとらないようにする必要があります。

fmt.Errorfがerrors.Wrapと比較して「役に立たない」かどうかという問題は、どちらもほぼ同じように冗長であるため、この問題と直交していると思います。 （実際のアプリケーションでは、どちらも使用していません。エラーとエラーが発生したコード行をログに記録する他の何かを使用しています。）

ですから、エラー処理が右側にあることを本当に気に入っている人もいると思います。 PerlとRubyのバックグラウンドから来たとしても、私はそれほど確信していません。

@lparコールスタックを自動的にキャプチャするため、 errors.Wrapを使用します。これらすべてのエラーメッセージは実際には必要ありません。 私はそれが起こった場所と、おそらく、エラーを生成した関数にどの引数が渡されたかをもっと気にします。 あなたはあなたが同じようなことをしているとさえ言っています-あなたのエラーメッセージにいくつかの文脈を提供するためにコードの行を記録してください。 エラーにコンテキストを与えながらボイラープレートを減らす方法を考えることができるとすると（これはほとんどここでの提案です）。

エラーは右側にあります。 私にとって、それは単に場所についてではなく、エラー処理が散らばっているコードを読むために必要な認知的負荷を減らすことについてです。 エラーが非常に重要であるため、エラーと同じくらい多くのスペースを使用してほしいという議論は買いません。 私は実際に彼らができるだけ離れることを望んでいます。 それらはメインストーリーではありません。

@creker

これは、ユーザー入力の誤りが原因でエラーを生成する本番システムのエラーよりも、些細な開発者エラーを説明している可能性が高くなります。 エラーを特定するために必要なのが行番号とファイルパスだけである場合は、コードを記述しただけで、何が問題なのかをすでに知っている可能性があります。

@例外に似ているため。 ほとんどの場合、コールスタックと例外メッセージで場所を特定し、エラーが発生した場所を特定できます。 より複雑なケースでは、少なくともエラーが発生した場所を知っています。 例外は、デフォルトでこの利点を提供します。 Goを使用すると、基本的にコールスタックをエミュレートしてエラーを連鎖させるか、実際のコールスタックを含める必要があります。

適切に記述されたコードでは、エラーが予想されるため、ほとんどの場合、行番号とファイルパスから正確な原因がわかります。 あなたは実際にそれが起こるかもしれない準備のためにいくつかのコードを書きました。 予期しないことが起こった場合は、そうです。コールスタックは原因を特定しませんが、検索スペースを大幅に削減します。

@なので

私の経験では、ユーザー入力エラーはほぼ即座に処理されます。 実際に問題となる本番エラーはコードの奥深くで発生し（たとえば、サービスがダウンして別のサービスがエラーをスローする）、適切なスタックトレースを取得するのに非常に役立ちます。 価値のあることとして、Javaスタックトレースは、メッセージではなく、本番環境の問題をデバッグするときに非常に役立ちます。

@creker
エラーは単なる値であり、関数の入力と出力の一部です。 彼らは「予期せぬ」ことはできませんでした。
関数がエラーを出した理由を知りたい場合は、テスト、ロギングなどを使用してください...

@gladkikhartem現実の世界では、それほど単純ではありません。 はい、関数シグネチャに戻り値としてエラーが含まれているという意味でエラーが発生することが予想されます。 しかし、私が期待することは、それが起こった理由とそれを引き起こした原因を正確に知っていることです。したがって、実際には、それを修正するか、まったく修正しないかを知っています。 悪いユーザー入力は通常、エラーメッセージを見るだけで簡単に修正できます。 プロトコルバッファを使用していて、一部の必須フィールドが設定されていない場合、ネットワーク上で受信するすべてのものを適切に検証すれば、それは予想され、修正するのは非常に簡単です。

この時点で、私はもはや私たちが議論していることを理解していません。 適切に実装された場合、スタックトレースまたはエラーメッセージのチェーンは非常に似ています。 これらは検索スペースを削減し、エラーを再現して修正するための有用なコンテキストを提供します。 必要なのは、十分なコンテキストを提供しながらエラー処理を単純化する方法を考えることです。 私は決して、適切な文脈よりも単純さが重要であると主張しているわけではありません。

これがJavaの議論です—すべてのエラーコードを別の場所に移動して、それを見る必要がないようにします。 私はそれが誤った方向に進んでいると思います。 これを行うためのJavaのメカニズムが大幅に失敗しただけでなく、コードを見るとき、エラーが発生したときのJavaの動作は、すべてが機能したときの動作と同じくらい重要です。

誰もその議論をしていません。 ここで説明していることを、すべてのエラー処理が1か所にある例外処理と混同しないようにしましょう。 それを「大失敗」と呼ぶのは単なる意見ですが、いずれにしても囲碁がそれに戻ることはないと思います。 Goエラー処理はまったく異なり、改善することができます。

@creker私は同じことを指摘し、意味のある/有用なエラーメッセージと見なされるものを明確にするように依頼しました。

真実は、コールスタックと関数の引数と引き換えに、可変品質のエラーメッセージテキスト（開発者がその瞬間にその知識でそれを書くというバイアスがあります）をいつでも提供することです。 エラーメッセージテキスト（ fmt.Errorfまたはerrors.New ）を使用すると、コールスタック/バックトレースを読み取りながら、ソースコード内のテキストを検索することになります（これは一見嫌われているようで、美的理由からではないことを願っています）ファイル/行番号（ errors.Wrapなど）で直接検索することに対応します。

2つの異なるスタイルですが、目的は同じです。これらの条件で実行時に何が起こったかを頭の中で再現しようとすることです。

このトピックに関して、問題＃19991は、意味のあるエラーを定義する2番目のスタイルへのアプローチの有効な要約を作成している可能性があります。

すべてのエラーコードを別の場所に移動して、それを見る必要がないようにします

@lpar 、エラー処理を右に移動することについての私のポイントに応答している場合：脚注/文末脚注（Java）と脚注（私の提案）には大きな違いがあります。 サイドノートは、コンテキストを失うことなく、わずかなアイシフトのみを必要とします。

@ gdm85

ソースコード内のテキストを検索することになります

スタックトレースと連鎖エラーメッセージが類似しているという意味とまったく同じです。 どちらも、エラーが発生するまでのパスを記録します。 メッセージの場合にのみ、メッセージを書くのに十分注意しないと、プログラムのどこからでも送信される可能性のある完全に役に立たないメッセージになってしまう可能性があります。 連鎖エラーの唯一の利点は、変数の値を記録できることです。 そして、それでさえ、関数の引数や一般的な変数の場合には自動化でき、少なくとも私にとっては、エラーから必要なほとんどすべてをカバーします。 それらはまだ値であり、必要に応じて「switch」と入力することができます。 しかし、ある時点でそれらをログに記録する可能性があり、スタックトレースを表示できることは非常に便利です。

Goがパニックで何をするかを見てください。 すべてのゴルーチンの完全なスタックトレースを取得します。 エラーの原因を突き止めてすぐに修正するのに何回役立ったか思い出せません。 それがいかに簡単であるか、私はしばしば驚かされました。 それは完全に流れ、言語全体が非常に予測可能であり、デバッガーさえ必要ありません。

Javaに関連するすべてのものには汚名があるようで、人々はしばしば議論を持ちません。 それは悪いからです。 私はJavaのファンではありませんが、そのような推論は誰の助けにもなりません。

繰り返しますが、エラーは開発者がバグを修正するためのものではありません。 これは、エラー処理の利点の1つです。 Javaの方法は、それがエラー処理であり、そうではないことを開発者に教えてきました。 エラーは、アプリケーション層とそれを超えるフロー層に存在する可能性があります。 Goのエラーは、システムが実行するリカバリ戦略を制御するために日常的に使用されます。コンパイル時ではなく、実行時に使用されます。

これは、言語がスタックを解きほぐし、エラーが発生する前に行ったすべてのメモリを失うことによってエラーの結果としてフロー制御を無効にする場合、理解できない可能性があります。 エラーは、Goの実行時に実際に役立ちます。 なぜ行番号のようなものを運ぶ必要があるのか​​わかりません-実行中のコードはそれをほとんど気にしません。

@なので

繰り返しますが、エラーは開発者がバグを修正するためのものではありません

それは完全にそして完全に間違っています。 エラーはまさにその理由によるものです。 それらはそれに限定されませんが、それは主な用途の1つです。 エラーは、システムに問題があることを示しているため、何かを行う必要があります。 予想される簡単なエラーの場合は、TCPタイムアウトなどの回復を試みることができます。 より深刻な問題については、ログにダンプし、後で問題をデバッグします。

これは、エラー処理の利点の1つです。 Javaの方法は、それがエラー処理であり、そうではないことを開発者に教えてきました。

Javaが何を教えてくれたかはわかりませんが、同じ理由で例外を使用します。実行時にシステムが実行するリカバリ戦略を制御するためです。 Goは、エラー処理に関して特別なことは何もありません。

これは、言語がスタックを解きほぐし、エラーが発生する前に行ったすべてのメモリを失うことによってエラーの結果としてフロー制御を無効にする場合、理解できない可能性があります

私のためではなく、誰かのためかもしれません。

エラーは、Goの実行時に実際に役立ちます。 なぜ行番号のようなものを運ぶ必要があるのか​​わかりません-実行中のコードはそれをほとんど気にしません。

コードのバグを修正することに関心がある場合は、行番号がそれを行う方法です。 これについて教えてくれたのはJavaではありません。Cにはまさにその理由で__LINE__と__FUNCTION__ます。 エラーをログに記録し、エラーが発生した正確な場所を記録する必要があります。 そして、何かがうまくいかないとき、あなたは少なくとも何かから始める必要があります。 回復不能なエラーによって引き起こされたランダムなエラーメッセージではありません。 そのような情報が必要ない場合は、無視してください。 それはあなたを傷つけません。 しかし、少なくともそれはそこにあり、必要なときに使用することができます。

ここの人々が会話を例外とエラー値にシフトし続ける理由がわかりません。 誰もその比較をしていませんでした。 議論された唯一のことは、スタックトレースが非常に有用であり、多くのコンテキスト情報を運ぶということです。 それが理解できない場合は、トレースが存在しない完全に異なる宇宙に住んでいる可能性があります。

それは完全にそして完全に間違っています。

しかし、私が参照している本番システムはまだ実行中であり、フロー制御にエラーを使用し、Goで記述され、エラーの伝播にスタックトレースを使用する言語の低速な実装に取って代わりました。

それが理解できない場合は、トレースが存在しない完全に異なる宇宙に住んでいる可能性があります。

エラータイプを返すすべての関数のコールスタック情報を連鎖させるには、自分の裁量でそれを行います。 スタックトレースは低速であり、セキュリティ上の理由からおもちゃプロジェクトの外部での使用には適していません。 彼らを一流のGo市民にして、単に思慮のないエラー伝播戦略を支援することは技術的な反則です。

そのような情報が必要ない場合は、無視してください。 それはあなたを傷つけません。

ソフトウェアの肥大化は、サーバーがGoで書き直される理由です。 表示されないものでも、パイプラインのスループットが低下する可能性があります。

TCPタイムアウトとログダンプの処理に関するやや無関係なレッスンではなく、この機能を使用することでメリットが得られる実際のソフトウェアの例をお勧めします。

スタックトレースは遅くなります

スタックトレースがエラーパスで生成されることを考えると、それらがどれほど遅いかは誰も気にしません。 ソフトウェアの通常の操作はすでに中断されています。

セキュリティ上の理由から、おもちゃのプロジェクト以外での使用には適していません

これまでのところ、「セキュリティ上の理由」のために、またはそのことについては、単一の本番システムがスタックトレースをオフにするのを見たことがありません。 一方、エラーを生成するためにコードがたどったパスをすばやく特定できることは非常に便利です。 そして、これは大規模なプロジェクト向けであり、多くの異なるチームがコードベースで作業しており、システム全体の完全な知識を持っている人は誰もいません。

表示されないものでも、パイプラインのスループットが低下する可能性があります。

いいえ、実際にはそうではありません。 前に述べたように、スタックトレースはエラー時に生成されます。 ソフトウェアが常にそれらに遭遇しない限り、スループットは1ビット影響を受けません。

スタックトレースがエラーパスで生成されることを考えると、それらがどれほど遅いかは誰も気にしません。 ソフトウェアの通常の操作はすでに中断されています。

真実ではない。

• 通常の操作の一部としてエラーが発生する可能性があります。
• エラーを回復してプログラムを続行できるため、パフォーマンスには問題があります。
• 1つのルーチンの速度を落とすと、ハッピーパスで動作している他のルーチンからリソースが失われます。

@ object88は、実際の製品コードを想像してください。 どのくらいのエラーが発生すると予想しますか？ あまり思いません。 少なくとも適切に作成されたアプリケーションでは。 ゴルーチンがビジーループにあり、反復ごとに常にエラーをスローする場合は、コードに問題があります。 しかし、そうだとしても、Goアプリケーションの大部分がIOバウンドであることを考えると、それは深刻な問題ではありません。

@なので

しかし、私が参照している本番システムはまだ実行中であり、フロー制御にエラーを使用し、Goで記述され、エラーの伝播にスタックトレースを使用する言語の低速な実装に取って代わりました。

申し訳ありませんが、これは私が言ったこととは何の関係もない無意味な文章です。 答えるつもりはありません。

スタックトレースは遅くなります

遅いですが、いくらですか？ それは重要ですか？ そうは思いません。 Goアプリケーションは一般にIOバウンドです。 この場合、CPUサイクルを追いかけるのはばかげています。 あなたはCPUを消費するGoランタイムではるかに大きな問題を抱えています。 バグの修正に役立つ便利な機能を捨てるのは議論の余地がありません。

セキュリティ上の理由から、おもちゃのプロジェクト以外での使用には適していません。

存在しない「セキュリティ上の理由」については、わざわざ取り上げるつもりはありません。 ただし、通常、アプリケーショントレースは内部に保存されており、開発者のみがそれらにアクセスできることを思い出してください。 そして、関数名を非表示にしようとすると、とにかく時間の無駄になります。 それはセキュリティではありません。 それについて詳しく説明する必要がないことを願っています。

セキュリティ上の理由で主張するなら、例えばmacOS / iOSについて考えてほしい。 すべてのスレッドのスタックとすべてのCPUレジスタの値を含むパニックやクラッシュダンプをスローしても問題ありません。 それらがこれらの「セキュリティ上の理由」の影響を受けているのを見ないでください。

彼らを一流のGo市民にして、単に思慮のないエラー伝播戦略を支援することは技術的な反則です。

これ以上主観的になれますか？ 「思いがけないエラー伝播戦略」それはどこで見ましたか？

ソフトウェアの肥大化は、サーバーがGoで書き直される理由です。 表示されないものでも、パイプラインのスループットが低下する可能性があります。

繰り返しますが、いくらですか？

TCPタイムアウトとログダンプの処理に関するやや無関係なレッスンではなく、この機能を使用することでメリットが得られる実際のソフトウェアの例をお勧めします。

この時点で、私はプログラマー以外の誰かと話しているようです。 トレースは、すべてのソフトウェアにメリットをもたらします。 これは、バグの修正に役立つすべての言語およびすべてのタイプのソフトウェアに共通の手法です。 詳細については、ウィキペディアをご覧ください。

コンセンサスなしに非常に多くの非生産的な議論があるということは、この問題を解決するためのエレガントな方法がないことを意味します。

@ object88
Goは他のゴルーチンのブロックが解除されるのを待つ必要があるため、すべてのゴルーチンのトレースを取得する場合は、スタックトレースが遅くなる可能性があります。
現在実行しているゴルーチンをトレースするだけであれば、それほど遅くはありません。

@creker
トレースは、すべてのソフトウェアに利益をもたらし、それはあなたがトレースしているかに依存します。 ほとんどのGoプロジェクトでは、並行性が関係しているため、スタックのトレースは良い考えではありませんでした。 データは前後に移動し、多くのものが相互に通信しており、一部のゴルーチンはほんの数行のコードです。 このような場合にスタックトレースがあると役に立ちません。
そのため、ログに書き込まれたコンテキスト情報でラップされたエラーを使用して、同じスタックトレースを再作成しますが、これは実際のゴルーチンスタックではなく、アプリケーションロジック自体にバインドされます。
猫をやれるように* .log | grep "orderID = xxx"を実行し、エラーの原因となった実際のアクションシーケンスのスタックトレースを取得します。
Goの同時実行性により、コンテキストが豊富なエラーはスタックトレースよりも価値があります。

@gladkikhartemは、適切な議論を書くために時間を割いて

私はあなたの議論を理解し、部分的に同意します。 それでも、少なくとも5つの関数のスタックを処理する必要があることに気付きました。 それは、何が起こっているのか、どこから探し始めるべきかを理解するのに十分な大きさです。 しかし、非常に小さなゴルーチンスタックトレースが多数ある非常に同時のアプリケーションでは、その利点が失われます。 私が同意すること。

@creker

実際の製品コードを想像してください。 どのくらいのエラーが発生すると予想しますか？ [...]、Goアプリケーションの大部分がIOバウンドであることを考えると、それは深刻な問題ではありません。

IOバウンド操作について言及するのは良いことです。 io.Reader Readメソッドは、EOFで正常なエラーを返します。 だから、それは幸せな道でたくさん起こるだろう。

@urandom

スタックトレースは、システムのプロファイリングに役立つ情報を意図せずに公開します。

• ユーザー名
• ファイルシステムパス
• バックエンドデータベースのタイプ/バージョン
• トランザクションフロー
• オブジェクト構造
• 暗号化アルゴリズム

平均的なアプリケーションがエラータイプでスタックフレームを収集するオーバーヘッドに気付くかどうかはわかりませんが、パフォーマンスが重要なアプリケーションでは、現在の関数呼び出しのオーバーヘッドのために、多くの小さなGo関数が手動でインライン化されます。 トレースすると悪化します。

Goの目標は、シンプルで高速なソフトウェアを使用することであり、トレースは一歩後退すると思います。 小さな関数を記述し、それらの関数からエラーを返すことができるはずです。これにより、従来とは異なるタイプのエラーや手動のインライン化が促進されます。

@creker

私はあなたにさらなる不協和音を引き起こす例を与えることを避けます。 ご不便をおかけして申し訳ございません。

名前がすぐにその機能を明らかにする新しいキーワード「returnif」を使用することを提案します。 また、エラー処理よりも多くのユースケースで使用できるほど十分な柔軟性があります。

例1（名前付きreturnを使用）：

a、err = something（b）
err！= nil {の場合
戻る
}

になります：

a、err = something（b）
returnif err！= nil

例2（名前付きリターンを使用しない）：

a、err：= something（b）
err！= nil {の場合
を返す、エラー
}

になります：

a、err：= something（b）
returnif err！= nil {a、err}

名前付き返品の例に関して、あなたはどういう意味ですか...

a, err = something(b)
returnif err != nil

@ambernardino
代わりにfmtツールを更新するだけで、言語構文を更新したり、新しい、役に立たないキーワードを追加したりする必要がないのはなぜですか。

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

また

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

@gladkikhartemアイデアは、エラーを伝播するたびにそれを入力することではなく、私はむしろこれを望み、同じように機能するはずです

a, err? := something(b)

@mrkaspa
アイデアは、コードをより読みやすくすることです。 コードの入力は問題ではなく、読み取りは問題です。

@gladkikhartem rustはそのアプローチを使用しており、読みにくくなるとは思わない

@gladkikhartem ?読みにくくなるとは思いません。 ノイズを完全に除去していると思います。 私にとっての問題は、ノイズがあると、有用なコンテキストを提供する可能性も排除されることです。 通常のエラーメッセージをプラグインしたり、エラーをラップしたりできる場所がわかりません。 コールスタックは明らかな解決策ですが、すでに述べたように、すべての人に役立つわけではありません。

@mrkaspa
そして、それはそれを読みにくくすると思います、次は何ですか？ 私たちは最善の解決策を見つけようとしていますか、それとも単に意見を共有しようとしていますか？

@creker
「？」 何が返されるのかはそれほど明確ではなく、もちろん人はこれが何をしているのかを知っている必要があるため、キャラクターは読者に認知的負荷を加えます。 そしてもちろん ？ サインは読者の心に疑問を投げかけます。

前に述べたように、err！= nilコンパイラを削除したい場合は、未使用のエラーパラメータを検出し、それらを自分で転送できます。
と

a, err? := doStuff(a,b)
err? := doAnotherStuff(b,z,d,g)
a, b, err? := doVeryComplexStuff(b)

読みやすくなります

a := doStuff(a,b)
doAnotherStuff(b,z,d,g)
a, b := doVeryComplexStuff(b)

同じ魔法で、タイプするものが少なく、考えるものが少ない

@gladkikhartemええと、読者が何か新しいことを学ぶ必要のない解決策はないと思います。 それは言語を変更した結果です。 トレードオフを行う必要があります。基本的な用語で何が行われているのかを正確に示す顔の構文に冗長性を持たせるか、冗長性を隠したり、構文の糖衣を追加したりできる新しい構文を導入します。他に方法はありません。 読者が学ぶために何かを追加するものを単に拒否することは逆効果です。 すべてのGo2の問題を閉じて、それを1日と呼ぶ方がよいでしょう。

あなたの例のように、それはさらに多くの魔法のものを導入し、開発者がエラーにコンテキストを提供できるようにする構文を導入するためのインジェクションポイントを非表示にします。 そして、最も重要なのは、どの関数呼び出しがエラーをスローする可能性があるかに関する情報を完全に隠すことです。 それはますます例外のようなにおいがします。 また、エラーを再スローすることだけを真剣に考えている場合は、スタックトレースが必須になります。これは、その場合にコンテキストを保持できる唯一の方法だからです。

元の提案は、実際にはすでにすべてをかなりうまくカバーしています。 それは十分に冗長であり、エラーをラップして有用なコンテキストを提供するのに適した場所を提供します。 しかし、主な問題の1つは、この魔法の「エラー」です。 魔法ではなく、冗長でもないので、醜いと思います。 ちょっと真ん中です。 それをより良くするかもしれないのは、より多くの魔法を導入することです。

||が、元のエラーを自動的にラップする新しいエラーを生成するとしたらどうでしょうか。 したがって、例は次のようになります

func Chdir(dir string) error {
    syscall.Chdir(dir) || &PathError{"chdir", dir}
    return nil
}

errが消えて、すべてのラッピングが暗黙的に処理されます。 次に、これらの内部エラーにアクセスする方法が必要です。 Inner() errorような別のメソッドをerrorインターフェースに追加しても、うまくいかないと思います。 1つの方法は、 unwrap(error) []errorような組み込み関数を導入することです。 それが行うことは、それらがラップされた順序ですべての内部エラーのスライスを返すことです。 そうすれば、内部エラーやそれらの範囲にアクセスできます。

errorは単なるインターフェイスであり、カスタムのerrorタイプのラップされたエラーを配置する場所が必要であることを考えると、これの実装には疑問があります。

私にとって、これはすべてのボックスにチェックマークを付けますが、やや不思議すぎるかもしれません。 しかし、エラーインターフェイスは定義上非常に特殊であるため、一級市民に近づけることは悪い考えではないかもしれません。 エラー処理は、通常のGoコードであり、特別なことは何もないため、冗長です。 それは紙の上や派手な見出しを作るのに良いかもしれませんが、エラーはそのような扱いを正当化するにはあまりにも特別です。 彼らは特別なケーシングが必要です。

エラーチェックの数または個々のチェックの長さを減らすことについての当初の提案はありますか？

後者の場合、条件文と繰り返し文が1つしかないという理由で、提案の必要性に異議を唱えるのは簡単です。 ループが嫌いな人もいますが、暗黙のループ構造も提供する必要がありますか？

これまでに提案された構文の変更は、興味深い思考実験として役立ちましたが、元の構文の変更ほど明確、発音可能、または単純なものはありません。 Goはbashではなく、エラーについて「魔法」である必要はありません。

私はますますこれらの提案を読み、議論が「何か新しいものを追加するので、それは悪い、読めない、すべてをそのままにしておく」に他ならない人々をますます見ています。

@as提案は、それが達成しようとしていることの要約を示しています。 何が行われているのかはかなり明確に定義されています。

オリジナルと同じくらい明確、発音可能、またはシンプル

どんな提案も新しい構文を導入し、一部の人々にとって新しいことは「読めない、複雑ななど」と同じように聞こえます。 それが新しいからといって、それがはっきりしていたり​​、発音しやすく、単純になったりすることはありません。 "||" と "？" 例は、それが何をするかを知っていれば、既存の構文と同じくらい明確で単純です。 それとも、「->」と「<-」は魔法が多すぎて、読者はそれらが何を意味するのかを知らなければならない、と不平を言い始める必要がありますか？ それらをメソッド呼び出しに置き換えましょう。

Goはbashではなく、エラーについて「魔法」である必要はありません。

それは完全に根拠がなく、何の議論としても数えられません。 Bashと関係があるのは、私を超えています。

@creker
はい、私はイベントにもっと魔法を導入したあなたに完全に同意します。 私の例は？の続きです少ないものを入力するというオペレーターの考え。

私たちは何かを犠牲にして、いくつかの変化ともちろんいくつかの魔法を導入する必要があることに同意します。 それは、使いやすさの長所とそのような魔法の短所のバランスにすぎません。

オリジナル|| 提案はかなり素晴らしく、実際にテストされていますが、私の意見ではフォーマットは醜いです、私はフォーマットをに変更することをお勧めします

syscal.Chdir(dir)
    || return &PathError{"chdir", dir}

PSあなたはそのような魔法の構文の変種についてどう思いますか？

syscal.Chdir(dir) {
    return &PathError{"chdir", dir}
}

@gladkikhartemはどちらも読みやすさの観点からはかなり見栄えがしますが、後者の方が悪い感じがします。 それは私がよくわからないこの奇妙なブロックスコープを紹介します。

構文を単独で見るのではなく、関数のコンテキストで見ることをお勧めします。 このメソッドには、いくつかの異なるエラー処理ブロックがあります。

func (l *Loader) processDirectory(p *Package) (*build.Package, error) {
        absPath, err := p.preparePath()
        if err != nil {
                return nil, err
        }
    fis, err := l.context.ReadDir(absPath)
    if err != nil {
        return nil, err
    } else if len(fis) == 0 {
        return nil, nil
    }

    buildPkg, err := l.context.Import(".", absPath, 0)
    if err != nil {
        if _, ok := err.(*build.NoGoError); ok {
            // There isn't any Go code here.
            return nil, nil
        }
        return nil, err
    }

    return buildPkg, nil
}

提案された変更は、この機能をどのようにクリーンアップしますか？

func (l *Loader) processDirectory(p *Package) (*build.Package, error) {
    absPath, err? := p.preparePath()
    fis, err? := l.context.ReadDir(absPath)
    if len(fis) == 0 {
        return nil, nil
    }

    buildPkg, err := l.context.Import(".", absPath, 0)
    if err != nil {
         if _, ok := err.(*build.NoGoError); ok {
             // There isn't any Go code here.
             return nil, nil
         }
         return nil, err
    }

    return buildPkg, nil
}

@bcmillsの提案の方が適しています。

func (l *Loader) processDirectory(p *Package) (*build.Package, error) {
    absPath := p.preparePath()        =? err { return nil, err }
    fis := l.context.ReadDir(absPath) =? err { return nil, err }
    if len(fis) == 0 {
        return nil, nil
    }
    buildPkg := l.context.Import(".", absPath, 0) =? err {
        if _, ok := err.(*build.NoGoError); ok {
            // There isn't any Go code here.
            return nil, nil
        }
        return nil, err
    }
    return buildPkg, nil
}

@ object88

func (l *Loader) processDirectory(p *Package) (p *build.Package, err error) {
        absPath, err := p.preparePath() {
        return nil, fmt.Errorf("prepare path: %v", err)
    }
    fis, err := l.context.ReadDir(absPath) {
        return nil, fmt.Errorf("read dir: %v", err)
    }
    if len(fis) == 0 {
        return nil, nil
    }

    buildPkg, err := l.context.Import(".", absPath, 0) {
        err, ok := err.(*build.NoGoError)
                if !ok {
            return nil, fmt.Errorf("buildpkg: %v",err)
        }
        return nil, nil
    }
    return buildPkg, nil
}

これを突っ込み続けます。 たぶん、より完全な使用例を思いつくことができます。

@erwbgy 、これは私には最高に見えますが、支払いがそれほど素晴らしいとは確信していません。

• エラー以外の戻り値は何ですか？ それらは常にゼロ値ですか？ 名前付きリターンに以前に割り当てられた値が_あった_場合、それはオーバーライドされますか？ 名前付きの値がエラー関数の結果を格納するために使用される場合、それは返されますか？
• ?演算子をエラー以外の値に適用できますか？ (!ok)?やok!?なことをしてもいいですか（割り当てと操作をバンドルしているので少し奇妙です）？ または、この構文はerrorのみ有効ですか？

@rodcorsi 、これは私をReadDirなく、 ReadBuildTargetDirectoryForFileInfoか、そのようなばかげたものだった場合はどうなるでしょうか。 または、おそらくあなたは多数の議論を持っています。 preparePathのエラー処理も、画面からはみ出してしまいます。 水平方向の画面サイズが制限されているデバイス（またはGithubのようにそれほど広くないビューポート）では、 =?部分が失われる可能性があります。 垂直スクロールは非常に得意です。 水平ではそれほど多くありません。

@gladkikhartem 、 errorインターフェースを実装するいくつかの（最後の？）引数に関連付けられているようです。 それは関数宣言によく似ています、そしてそれはただ..._感じ_奇妙です。 okスタイルの戻り値に関連付ける方法はありますか？ 全体として、1行しか購入していません。

@ object88
ワードラップは、非常に幅広いコードの問題を解決します。 広く使われていませんか？

非常に長い関数呼び出しに関する@ object88 。 ここで主な問題に対処しましょう。 問題は、画面から押し出されたエラー処理ではありません。 問題は、長い関数名や引数の大きなリストです。 エラー処理が画面外にあることについて議論する前に、これを修正する必要があります。

デフォルトでワードラップに設定されているIDEまたはコードフレンドリーなテキストエディタはまだ見たことがありません。 そして、ページがロードされた後にCSSを手動でハッキングする以外に、Githubを使用してそれを行う方法をまったく見つけていません。

そして、私はコード幅が重要な要素であると思います-それはこの提案の推進力である_可読性_を物語っています。 主張は、エラーの周りに「コードが多すぎる」ということです。 機能がないというわけではなく、エラーを他の方法で実装する必要があるというわけではありませんが、コードがうまく読み取れないということです。

@ object88
はい、このコードは、エラーインターフェイスを最後のパラメータとして返すすべての関数で機能します。

行の節約に関しては、より少ない行数でより多くの情報を入力することはできません。 コードは均等に分散し、密度が高すぎたり、すべてのステートメントの後にスペースを入れたりしないようにする必要があります。
私はそれが関数宣言のように見えることに同意しますが、同時にそれは既存の場合と非常に似ています...; err！= nil {ステートメントなので、人々はあまり混乱しません。

コード幅は重要な要素です。 80行のエディターと80行のコードが関数呼び出しであり、その後に||がある場合はどうなりますか？ 返しますか？ 関数が何かを返すことを識別できません。これは、読み取るものが、戻り値のない有効なgoコードになるためです。

完全を期すために、 ||構文、自動マジックエラーラッピング、およびエラー以外の戻り値の自動ゼロ化を使用した例を示します。

func (l *Loader) processDirectory(p *Package) (*build.Package, error) {
        absPath := p.preparePath() || errors.New("prepare path")
    fis := l.context.ReadDir(absPath) || errors.New("ReadDir")
    if len(fis) == 0 {
        return nil, nil
    }

    buildPkg, err := l.context.Import(".", absPath, 0)
    if err != nil {
        if _, ok := err.(*build.NoGoError); ok {
            // There isn't any Go code here.
            return nil, nil
        }
        return nil, err
    }

    return buildPkg, nil
}

他の戻り値についての質問について。 エラーが発生した場合、すべての場合で値はゼロになります。 それが重要だと思う理由については、すでに説明しました。

問題は、あなたの例がそもそも関係していないということです。 しかし、それでも、少なくとも私にとっては、この提案が何を表しているのかを示しています。 私が解決したいのは、最も一般的で乱暴に使用されているイディオムです

err := func()
if err != nil {
    return err
}

この種のコードは、一般にエラー処理の大きな部分（最大ではないにしても）であることに同意できます。 したがって、その場合を解決することは論理的です。 そして、エラーにもっと関係することをしたい場合は、いくつかのロジックを適用してください-それを実行してください。 ここで、プログラマーが読んで理解するための実際のロジックが冗長性である必要があります。 私たちが必要としないのは、無意識の定型文を読むためにスペースと時間を無駄にすることです。 それは無意味ですが、それでもGoコードの重要な部分です。

暗黙的にゼロ値を返すことについての以前の話について。 エラー時に意味のある値を返す必要がある場合は、それを選択してください。 ここでも、冗長性は優れており、コードを理解するのに役立ちます。 もっと複雑なことをする必要がある場合は、シンタックスシュガーを捨てても問題ありません。 また、 ||は、両方のケースを解決するのに十分な柔軟性があります。 エラー以外の値は省略でき、暗黙的にゼロになります。 または、必要に応じて明示的に指定することもできます。 エラーを返し、他のすべてをゼロにしたい場合も含まれる、これに関する別の提案さえあることを覚えています。

@ object88

主張は、エラーの周りに「コードが多すぎる」ということです。

それは単なるコードではありません。 主な問題は、エラーの周りに無意味な定型文が多すぎて、エラー処理の非常に一般的なケースがあることです。 読む価値のあるものがある場合、冗長性は重要です。 エラーを再スローすることを除いて、 if err == nil then return errは何の価値もありません。 このようなプリミティブロジックの場合、多くのスペースが必要になります。 そして、すべてがエラーを返す可能性のあるロジック、ライブラリ呼び出し、ラッパーなどがあればあるほど、この定型文が重要なもの、つまりコードの実際のロジックを支配し始めます。 そして、そのロジックには、実際にはいくつかの重要なエラー処理ロジックが含まれている可能性があります。 しかし、それはその周りのほとんどの定型文のこの反復的な性質で失われます。 そしてそれは解決することができ、Goが競合する他の現代言語はそれを解決しようとします。 エラー処理は非常に重要であるため、通常のコードだけではありません。

@creker
err != nil return errが定型的すぎる場合、私たちが恐れているのは、スタックのエラーを転送する簡単な方法を作成する場合、統計的にプログラマー、特にジュニアは、実行するのではなく、最も簡単な方法を使用することです。特定の状況で何が適切か。
これはGoのエラー処理と同じ考えです-それはあなたにまともなことをすることを強制します。
したがって、この提案では、他の人がエラーを慎重に処理してラップすることを奨励したいと思います。

単純なエラー処理は見栄えが悪く、実装に時間がかかるようにする必要がありますが、ラッピングまたはスタックトレースを使用した適切なエラー処理は見栄えがよく、簡単に実行できます。

@gladkikhartem私はいつも、古代の編集者についてのこの議論を

@gladkikhartem Goにはすでにその問題があり、それについては何もできないと思います。 ちなみに、Goが行っていないコンパイルの失敗や実行時のパニックで開発者を強制するまで、開発者は常に怠惰になります。

Goが実際に行うことは、何も強制しないことです。 Goがエラーの処理を強制するという概念は誤解を招きやすく、常にそうでした。 Goの作者は、ブログの投稿や会議の講演でそうするように強制します。 実際の言語では、やりたいことが何でもできます。 そして、ここでの主な問題は、Goがデフォルトで選択するものです。デフォルトでは、エラーは黙って無視されます。 それを変える提案さえあります。 Goがあなたにまともなことを強制することについてだったなら、それは次のことをするべきです。 コンパイル時にエラーを返すか、返されたエラーが適切に処理されない場合は実行時にパニックになります。 私が理解していることから、Rustはこれを行います-エラーはデフォルトでパニックになります。 それが私が正しいことを強制することと呼んでいるものです。

Goでエラーを処理することを実際に強制したのは、開発者の良心であり、他には何もありません。 しかし、それは常に諦めたくなります。今のところ、関数のシグネチャを明示的に読み取らないと、エラーが返されることを誰も教えてくれません。 実際の例があります。 長い間、 fmt.Printlnがエラーを返すことをfmt.Printlnた。 私はその戻り値を使いません。ただ印刷したいだけです。 ですから、それが何を返すのかを見る動機はありません。 それはCが抱えているのと同じ問題です。 エラーは値であり、実行時にコードが壊れて、処理されていない例外などの有用なパニックによるクラッシュが発生しないため、エラーについて何もわからなくなるまで、必要なすべてを無視できます。

@gladkikhartemは、この提案について私が理解していることから、開発者がエラーを慎重にラップすることを奨励するものではありません。 それは、提案を思い付く人々に、それをカバーすることを忘れないように促すことです。 多くの場合、エラーを再スローするだけの解決策を思い付くので、実際にはより多くのコンテキストを与えてから再スローすることを忘れてしまいます。

私は主に、Goエラー処理を簡素化したい人々に、エラーを変更せずに返すだけでなく、エラーの周りにコンテキストを簡単にラップできるようにする方法を考えるように促すためにこの提案を書いています。

@creker
私のエディターは100文字幅です。これは、ファイルエクスプローラー、gitコンソールなどがあるためです。私たちのチームでは、100文字を超えるコードを作成する人は誰もいません。それはばかげています（いくつかの例外を除いて）

Goはエラー処理を強制していませんが、リンターは強制します。 （たぶん、これのためにリンターを書くべきですか？）

さて、私たちが解決策を思い付くことができず、誰もが自分のやり方で提案を理解しているなら、私たちが必要とするもののいくつかの要件を指定してみませんか？ 最初に要件について合意し、次にソリューションを開発する方がはるかに簡単な作業です。

例えば：

1. 新しい提案の構文には、テキストでreturnステートメントを含める必要があります。そうしないと、何が起こっているのかが読者にはわかりません。 （ 同意する同意しません ）
2. 新しい提案は、複数の値を返す関数をサポートする必要があります（同意する/同意しない）
3. 新しい提案はより少ないスペースを取る必要があります（1行、2行、同意しない）
4. 新しい提案は、非常に長い表現を処理できる必要があります（同意する/同意しない）
5. 新しい提案では、エラーが発生した場合に複数のステートメントを許可する必要があります（同意する/同意しない）
6. ....。

@creker 、私の開発の約75％はVSCodeの15インチラップトップで行われています。水平方向のスペースを最大化しますが、特に並べて編集する場合はまだ制限があります。学生の間でそれを賭けます、デスクトップよりもはるかに多くのラップトップがあります。私たちは誰もが大判モニターを持っていると予想しているので、言語の親しみやすさを制限したくありません。

残念ながら、画面がどれほど大きくても、githubはビューポートを制限します。

@gladkikhartem

ここでは初心者の怠惰が当てはまりますが、これらの例のいくつかでerrors.Newを自由に使用していることも、言語の理解が不足していることを示しています。 エラーは動的でない限り戻り値に割り当てるべきではありません。それらのエラーが同等のパッケージスコープ変数に入れられる場合、構文はページ上で短くなり、実際には本番コードでも受け入れられます。 Goエラー処理「ボイラープレート」で最も苦しんでいる人は、ほとんどのショートカットを使用し、エラーを適切に処理するための十分な経験がありません。

何がsimplifying error handling構成するかは明らかではありませんが、前例はless runes != simpleです。 単純化のために、定量化可能な方法で構成を測定できる修飾子がいくつかあると思います。

• 構成する方法の数は表現されます
• そのコンストラクトと他のコンストラクトとの類似性、およびそれらのコンストラクト間の凝集性
• コンストラクトによって要約された論理演算の数
• 自然言語との構成の類似性（つまり、否定がないなど）

たとえば、元の提案では、エラーを伝播する方法の数が2から3に増えています。これは論理ORに似ていますが、セマンティクスが異なります。 これは、複雑度の低い条件付きリターンを要約したものです（ copyまたはappend 、または>>と比較して）。 新しい方法は古い方法よりも自然ではなく、大声で話すとおそらくabs, err := path(foo) || return err -> if theres an error, it's returning errになります。その場合、垂直バーを使用できる理由は謎になります。コードレビューで大声で言ったのと同じように書くことができます。

@なので
less runes != simple完全に同意します。
簡単に言うと、読みやすく理解しやすいという意味です。
goに慣れていない人は、goを読んで、その機能を理解する必要があります。
それは冗談のようでなければなりません-あなたはそれを説明する必要はありません。

現在のエラー処理は実際には理解できますが、 if err != nil return.が多すぎる場合は完全に読み取ることはできません。

@ object88大丈夫です。 この議論はかなり頻繁に出てくるので、私はもっと一般的に言いました。 たとえば、Goの記述に使用できるとんでもない古代のターミナル画面を想像してみましょう。 それはどのような議論ですか？ それのばかげたことの限界はどこにありますか？ 私たちがそれについて真剣に考えているなら、私たちは難しい事実を観察する必要があります-最も人気のある画面サイズと解像度は何ですか？ そしてそれからのみ、何かを描くことができます。 しかし、議論は通常、誰も使用しない画面サイズを想像するだけですが、誰かが使用できる可能性はわずかです。

@gladkikhartemいいえ、リンターはあなたを強制しません、彼らは示唆します。 ここには大きな違いがあります。 これらはオプションであり、Goツールチェーンの一部ではなく、提案を行うだけです。 強制は、コンパイルエラーまたはランタイムエラーの2つだけを意味します。 他のすべては、選択するための提案とオプションです。

私は同意します。提案はすべての側面を完全に網羅しているわけではないので、私たちが望むものをより適切に策定する必要があります。

@なので

新しい方法は古い方法よりも自然ではなく、大声で話すとおそらく腹筋になるでしょう、err：= path（foo）|| return err->エラーが発生した場合、errが返されます。その場合、コードレビューで大声で述べたのと同じように垂直バーを使用できるのはなぜか謎です。

新しい方法は、1つの理由だけで自然ではありません。現在、言語の一部ではありません。 他に理由はありません。 すでにその構文でGoを想像してみてください-あなたがそれに精通しているのでそれは自然でしょう。 -> 、 select 、 goなど、他の言語にはないものに精通しているように。 リターンの代わりに垂直バーを使用できるのはなぜですか？ 質問で答えます。 ループで同じことができるのに、1回の呼び出しでスライスを追加する方法があるのはなぜですか？ ループで同じことができるのに、1回の呼び出しでリーダーからライターのインターフェイスにコピーする方法があるのはなぜですか？ などなどなどコードをよりコンパクトで読みやすくしたいからです。 Goがすでに多くの例でそれらと矛盾している場合、あなたはこれらの議論をしているのです。 繰り返しになりますが、それが新しく、まだ言語になっていないという理由だけで、もっとオープンになり、何も撃ち落とさないようにしましょう。 それでは何も達成できません。 問題があります、多くの人々が解決策を求めています、それに対処しましょう。 Goは、それに追加されたものによって冒涜される神聖な理想的な言語ではありません。

ループで同じことができるのに、1回の呼び出しでスライスを追加する方法があるのはなぜですか？

ifステートメントのエラーチェックを書くのは簡単ですが、 append実装を見てみたいと思います。

ループで同じことができるのに、1回の呼び出しでリーダーからライターのインターフェイスにコピーする方法があるのはなぜですか？

リーダーとライターは、コピー操作のソースと宛先、バッファリング戦略、場合によってはループ内の番兵の値さえも抽象化します。 その抽象化をループとスライスで表現することはできません。

Goがすでに多くの例でそれらと矛盾しているとき、あなたはこれらの議論をしている。

少なくともそれらの例ではそうではないと思います。

繰り返しになりますが、それが新しく、まだ言語になっていないという理由だけで、もっとオープンになり、何も撃ち落とさないようにしましょう。

Goには互換性が保証されていることを考えると、新機能がひどい場合は永遠に対処しなければならないため、新機能を最も精査する必要があります。 これまで誰もここで行ったことはありませんが、実際の概念実証が作成され、小さな開発チームで使用されています。

いくつかの提案（ジェネリックなど）の履歴を見ると、それを実行した後、「うわー、これは実際には良い解決策ではないので、まだ変更を加えないでください」という認識がよくあることがわかります。 代替案は提案に満ちた言語であり、それらをさかのぼって排除する簡単な方法はありません。

ワイドスクリーンとシンスクリーンについて、考慮すべきもう1つのことはマルチタスクです。

エディターを見つめるだけでなく、コンテキストを別のウィンドウに完全に切り替えて関数を検索するのではなく、コードを少しまとめるときに他の何かを追跡するために、複数のウィンドウを並べて配置する場合があります。エディターに戻ります。

@なので
提案された機能のほとんどが実用的ではないことに完全に同意し、私はそれを考え始めています|| と ？ ものが当てはまる可能性があります。

@creker
copy（）とappend（）は、実装するのが簡単なタスクではありません

私はCI / CDにリンターを持っており、文字通りすべてのエラーを処理するように強制されます。 それらは言語の一部ではありませんが、それは気にしません-私はただ結果が必要です。
（ちなみに、私は強い意見を持っています-誰かがGoでリンターを使用していない場合-彼はただ........）

画面サイズについて-それは真剣に、面白くさえありません。 この無関係な議論をやめてください。 画面は必要なだけ広くすることができます。コードの|| return &PathError{Err:err}部分が表示されない可能性が常にあります。 「ide」という単語をグーグルで検索して、コードに使用できるスペースの種類を確認してください。

そして、他の人のテキストをよく読んでください、私はGoがあなたにすべてのエラーを処理することを強制するとは言いませんでした

これはGoのエラー処理と同じ考えです-それはあなたにまともなことをすることを強制します。

@gladkikhartem Goは、エラー処理に関して何も強制しません。それが問題です。 まともなことかどうかは関係ありません、それはただのピッキングです。 私にとっては、 fmt.Printlnようなものを除いて、すべての場合にすべてのエラーを処理することを意味します。

誰かがGoでリンターを使用していない場合-彼はただ

多分そうです。 しかし、何かが実際に強制されていない場合、それは飛ぶつもりはありません。 使用する人もいれば、使用しない人もいます。

画面サイズについて-それは真剣に、面白くさえありません。 この無関係な議論をやめてください。

どういうわけか意思決定に影響を与えるはずの乱数を投げ始めたのは私ではありません。 私は問題を理解していると明確に述べていますが、それは客観的でなければなりません。 「私は80シンボル幅のIDEを持っています、Goはそれを説明し、他のすべてを無視する必要があります」ではありません。

私の画面サイズについて話している場合。 Visual Studio Codeは、270個の水平方向のスペースのシンボルを提供します。 そんなに多くのスペースを取るのが普通だと主張するつもりはありません。 しかし、コメント付きの構造体、特に長い名前のフィールドタイプを考慮すると、私のコードは簡単に120シンボルを超える可能性があります。 ||構文を使用する場合、3〜5個の引数の関数呼び出しとカスタムメッセージでラップされたエラーの場合、100〜120に簡単に収まります。

||ようなものが実装された場合、gofmtはおそらくそれを1行に書き込むように強制するべきではありません。 場合によっては、スペースがかかりすぎることがあります。

@erwbgy 、これは私には最高に見えますが、支払いがそれほど素晴らしいとは確信していません。

@ object88私にとっての

val, err := func()
if err != nil {
    return nil, errors.WithStack(err)
}

より単純：

val, err? := func()

より複雑なエラー処理が現在の方法で実行されることを妨げるものはありません。

エラー以外の戻り値は何ですか？ それらは常にゼロ値ですか？ 名前付きリターンに以前に割り当てられた値があった場合、それはオーバーライドされますか？ 名前付きの値がエラー関数の結果を格納するために使用される場合、それは返されますか？

他のすべての戻りパラメーターは適切なnil値です。 名前付きパラメーターの場合、すでに何らかの値が割り当てられていることが保証されているため、以前に割り当てられた値が保持されると思います。

できますか？ 演算子はエラー以外の値に適用されますか？ （！ok）のようなことをしてもいいですか？ またはOK !? （割り当てと操作をバンドルしているので、これは少し奇妙です）？ それとも、この構文はエラーに対してのみ有効ですか？

いいえ、エラー値以外にこの構文を使用することは意味がないと思います。

「必須」の関数は、より読みやすいコードを求めて必死になって増殖していると思います。

sqlx

db.MustExec(schema)

htmlテンプレート

var t = template.Must(template.New("name").Parse("html"))

パニック演算子を提案します（「演算子」と呼ぶべきかどうかわかりません）

a,  😱 := someFunc(b)

と同じですが、おそらくより即時

a, err := someFunc(b)
if err != nil {
  panic(err)
}

😱入力するのはおそらく難しすぎるので、！、!!、または

a,  !! := someFunc(b)

!! = maybeReturnsError()

多分 ！！ パニックと！ 戻り値

私の2セントの時間。 スタックトレースに標準ライブラリのdebug.PrintStack()だけを使用できないのはなぜですか？ エラーが発生した最も深いレベルでのみスタックトレースを出力するという考え方です。

スタックトレースに標準ライブラリのdebug.PrintStack()だけを使用できないのはなぜですか？

エラーは多くのスタックを通過する可能性があります。 それらはチャネルを介して送信したり、変数に格納したりすることができます。エラーが最初に生成されたフラグメントを知るよりも、これらの遷移点を知る方が役立つことがよくあります。

さらに、スタックトレース自体には、多くの場合、内部（エクスポートされていない）ヘルパー関数が含まれています。 これは、予期しないクラッシュをデバッグしようとしているときに便利ですが、通常の操作中に発生するエラーには役立ちません。

完全なプログラミング初心者にとって最もユーザーフレンドリーなアプローチは何ですか？

私はより単純なバージョンを見つけました。 if !err 1つだけ必要です
特別なもの、直感的なもの、余分な句読点、非常に小さなコードはありません

`` `行く
absPath、err：= p.preparePath（）
nilを返し、エラーの場合はエラー

err：= doSomethingWith（absPath）if！err
doSomethingElse（）if！err

doSomethingRegardlessOfErr（）

//エラーを1か所で処理します。 必要に応じて; インデントなしのキャッチのような
エラーの場合{
「コード汚染のないエラー」を返す、エラー
}
`` `

err := doSomethingWith(absPath) if !err
doSomethingElse() if !err

おかえりなさい、古き良きおたふく風邪の投稿条件;-)

ありがとう、でもありません。

@dmajkicこれは、「追加のコンテキスト情報とともにエラーを返す」のに役立つことは何もしません。

@erwbgyこの問題のタイトルは_proposalです：Go 2：||でエラー処理を簡素化しますエラーsuffix_私のコメントはその文脈にありました。 前の議論に足を踏み入れたらごめんなさい。

@cznicうん。 事後条件は順調ではありませんが、事前条件も汚染されているように見えます。

if !err; err := doSomethingWith(absPath)
if !err; doSomethingElse()

@dmajkic提案には、タイトルだけではありません。ianlancetaylorは、エラーを処理する3つの方法を説明し、追加情報を使用してエラーを簡単に返すことができる提案はほとんどないことを具体的に指摘しています。

@erwbgy私は経験しました。それらはすべて、新しいキーワード（ try() ）の追加または特殊な英数字以外の文字の使用を中継します。 個人的に-私はそれが好きではありません。コードが！ "＃$％＆でオーバーロードされていると、罵倒のように不快に見える傾向があるからです。

私は、この問題の最初の数行が何を述べているかに同意し、感じています。Goコードが多すぎるとエラー処理が行われます。 私が行った提案はその感情に沿ったものであり、追加のキーワードやキー文字を必要とせずに、Goが現在感じているものに非常に近い提案をしています。

条件付き延期はどうですか

func something() (int, error) {
    var error err
    var oth err

    defer err != nil {
        return 0, mycustomerror("More Info", err)
    }
    defer oth != nil {
        return 1, mycustomerror("Some other case", oth)
    }

    _, err = a()
    _, err = b()
    _, err = c()
    _, oth = d()
    _, err = e()

    return 2, nil
}


func something() (int, error) {
    var error err
    var oth err

    _, err = a()
    if err != nil {
        return 0, mycustomerror("More Info", err)
    }
    _, err = b()
    if err != nil {
        return 0, mycustomerror("More Info", err)
    }
    _, err = c()
    if err != nil {
        return 0, mycustomerror("More Info", err)
    }
    _, oth = d()
    if oth != nil {
        return 1, mycustomerror("Some other case", oth)
    }
    _, err = e()
    if err != nil {
        return 0, mycustomerror("More Info", err)
    }

    return 2, nil
}

これにより、 deferの意味が大幅に変わります。これは、スコープの最後で実行されるものであり、スコープを早期に終了させるものではありません。

彼らがこの言語でTryCatchを導入すれば、これらすべての問題は非常に簡単な方法で解決されます。

彼らはこのようなものを紹介する必要があります。 errorの値がnil以外に設定されている場合、現在のワークフローが中断され、catchセクションが自動的にトリガーされ、finallyセクションと現在のライブラリも変更なしで機能する可能性があります。 問題が解決しました！

try (var err error){
     i, err:=DoSomething1()
     i, err=DoSomething2()
     i, err=DoSomething3()
} catch (err error){
   HandleError(err)
   // return err  // similar to throw err
} finally{
  // Do something
}

マルセルはこれらの方針に沿って考えているようです。

• https://github.com/gopherchina/conference/blob/master/2018/1.3%20Rethinking%20Errors%20for%20Go%202.pdf

@sbinetこれは何もないよりはましですが、誰もが慣れ親しんでいるのと同じtry-catchパラダイムを使用するだけの場合は、はるかに優れています。

@KamyarM変数がゼロ以外の値に設定されている場合は常に、例外をスローするメカニズムを追加することを提案しているようです。 それは「誰もがよく知っているパラダイム」ではありません。 私はそのように機能する言語を知りません。

例外のようには機能しない「例外」もあるSwiftに似ています。

さまざまな言語で、try catchは実際にはセカンドクラスのソリューションであることが示されていますが、GoはMaybeモナドなどのようにそれを解決できないと思います。

@ianlancetaylor C ++、Java、C＃などの他のプログラミング言語でTry-Catchを参照しましたが、ここでの解決策ではありませんでした。 GoLangに1日目からTry-Catchがあった方が良かったので、この方法のエラー処理を処理する必要はありませんでした（これは実際には新しいものではありませんでした。必要に応じて、他のプログラミング言語で同じGoLangエラー処理を記述できます。そのようにコーディングする）が、私が提案するのは、エラーオブジェクトを返す可能性のある現在のライブラリとの下位互換性を持たせる方法でした。

Javaの例外は列車事故であるため、ここ@KamyarMでは完全に反対する必要があります。 なじみのあるものだからといって、それが良い選択だとは限りません。

私が意味したのは。

@KamyarM説明してくれてありがとう。 例外を明示的に検討して拒否しました。 エラーは例外ではありません。 それらはあらゆる種類の完全に通常の理由で起こります。 https://blog.golang.org/errors-are-values

例外的かどうかはわかりませんが、ボイラープレートの処理エラーによるコードの膨張の問題は解決されます。 同じ問題により、Goとほぼ同じように機能するObjective-Cが機能しなくなりました。 エラーはNSErrorタイプの値であり、特別なことは何もありません。 また、ifのロードとエラーラッピングでも同じ問題が発生します。 それがSwiftが状況を変えた理由です。 それらは2つの組み合わせで終わりました-それは実行を終了することを意味する例外のように機能し、あなたは例外をキャッチする必要があります。 ただし、スタックを巻き戻すことはなく、通常のリターンのように機能します。 したがって、制御フローに例外を使用することに反対する技術的な議論は、そこには当てはまりません。これらの「例外」は、通常の戻りと同じくらい高速です。 糖衣構文のようなものです。 しかし、Swiftには固有の問題があります。 Cocoa APIの多くは非同期（コールバックとGCD）であり、その種のエラー処理とは互換性がありません。例外は、awaitのようなものがなければ役に立ちません。 しかし、ほとんどすべてのGoコードは同期しており、これらの「例外」は実際に機能する可能性があります。

@urandom
Javaの例外は悪くありません。 問題は、それを使用する方法を知らない悪いプログラマーにあります。

あなたの言語にひどい機能がある場合、誰かが最終的にその機能を使用するでしょう。 あなたの言語にそのような機能がない場合、0％の可能性があります。 簡単な数学です。

@ try-catchがひどい機能であることに同意しません。 これは非常に便利な機能であり、私たちの生活をはるかに楽にしてくれます。それがここでコメントしている理由です。GoogleGoLangチームが同様の機能を追加している可能性があります。 私は個人的にGoLangのif-elsesエラー処理コードが嫌いで、そのdefer-panic-recoverの概念はあまり好きではありません（try-catchに似ていますが、Try-Catch-Finallyブロックの場合ほど整理されていません） 。 多くの場合、コードに非常に多くのノイズが追加され、コードが読み取れなくなります。

ボイラープレートなしでエラーを処理する機能は、言語にすでに存在します。 例外ベースの言語を使用する初心者を満足させるために機能を追加することは、良い考えではないようです。

そして、ボイラープレートでまったく同じ問題を抱えているC / C ++、Objective-Cから来ているのは誰ですか？ そして、Goのような現代語がまったく同じ問題に苦しんでいるのを見るのはイライラします。 だからこそ、価値観がとても偽物でばかげていると感じるので、エラーに関するこの全体的な誇大宣伝は、すでに何年も、何十年も行われています。 囲碁はその経験から何も学ばなかったような気がします。 特に、実際にもっと良い方法を見つけようとしているSwift / Rustを見てください。 例外を除いて解決されたJava / C＃のような既存のソリューションで解決しますが、少なくともそれらははるかに古い言語です。

@KamyarM鉄道指向プログラミングを使用したことがありますか？ ビーム？

例外をあまり称賛しないでしょう、もしあなたがこれらを使うなら、私見。

@ShalokShalomあまりありません。 しかし、それは単なるステートマシンではありませんか？ 失敗した場合はこれを行い、成功した場合はこれを行いますか？ すべてのタイプのエラーが例外のように処理されるわけではないと思います。 ユーザー入力の検証のみが必要な場合は、検証エラーの詳細を含むブール値を返すだけです。 例外は、IOまたはネットワークアクセスまたは不正な関数入力に限定する必要があります。エラーが非常に重大であり、実行パスの正常な実行を停止したい場合に備えてください。

Try-Catchが良くないと言う人がいる理由の1つは、そのパフォーマンスのためです。 おそらく、例外が発生する可能性のある場所ごとにハンドラーマップテーブルを使用することが原因です。 If Error check（エラーの有無に関係なく常にチェックされます）と比較すると、例外でさえ高速（例外が発生しない場合はゼロコストですが、実際に発生する場合ははるかにコストがかかります）であるとどこかで読みました。 それ以外は、Try-Catch構文に問題はないと思います。 構文ではなく、コンパイラによって実装される方法だけが異なります。

@ShalokShalomこれを確認してください：
https://mortoray.com/2013/09/12/the-true-cost-of-zero-cost-exceptions/

C / C ++から来た人々は、例外がなく、
賢明な選択をし、それが「現代的」であると主張する人々に抵抗し、
読みやすいワークフローについて神に感謝します（特にC ++の後）。

午前3時46分で火、2018年4月17日には、Antonenkoアルテム[email protected]
書きました：

そして、私たちが同じものを持っているC / C ++、Objective-Cから来ているのはどうですか？
ボイラープレートの正確な問題？ そして現代語を見るのはイライラする
Goのようにまったく同じ問題に苦しんでいます。 だからこの全体の誇大宣伝
値がとても偽物でばかげていると感じるのでエラーの周り-それはすでに行われています
何年も、何十年も。 囲碁はそこから何も学ばなかったような気がします
経験。 特に実際に見つけようとしているSwift / Rustを見る
より良い方法。 Java / C＃のような既存のソリューションで解決します
例外ですが、少なくともそれらははるかに古い言語です。

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

@kirillx C ++のように例外が欲しいと言ったことは一度もありません。 私のコメントをもう一度読んでください。 そして、それはエラー処理がさらにひどいCと何の関係があるのでしょうか？ ボイラープレートがたくさんあるだけでなく、延期と複数の戻り値がないため、ポインター引数を使用して値を返し、gotoを使用してクリーンアップロジックを整理する必要があります。 Goは同じエラーの概念を使用しますが、遅延と複数の戻り値に関する問題のいくつかを解決します。 しかし、定型文はまだそこにあります。 他の現代言語も例外を望んでいませんが、その冗長性のためにCスタイルで解決することも望んでいません。 これが、私たちがこの提案を持ち、この問題に非常に関心を持っている理由です。

例外を提唱する人々はこの記事を読むべきです： https ：

Java / C ++スタイルの例外が本質的に悪い理由は、特定の実装のパフォーマンスとは何の関係もありません。 例外は、BASICの「エラー時のgoto」であり、gotoが有効になる可能性のあるコンテキストでは表示されないため、問題があります。 例外は、エラー処理を簡単に忘れてしまう場所に隠します。 Javaのチェックされた例外はその問題を解決するはずでしたが、実際には、人々が例外をキャッチして食べたり、スタックトレースをどこにでもダンプしたりしたため、解決しませんでした。

私はほとんどの週にJavaを作成していますが、パフォーマンスがどれほど高くても、GoでJavaスタイルの例外を確認したくないことを強調しています。

@lparはすべてのforループではありませんが、whileループは、

一方、forおよびif / elseは、実行の流れが目に見えない形で他の場所にジャンプすることを伴わず、マーカーがないことを示します。

誰かがGoLangで前の呼び出し元にエラーを渡し、その呼び出し元が前の呼び出し元にエラーを返すなど（多くのコードノイズを除く）の場合はどうなりますか？ 誰がエラーを処理するのかを確認するために、どのくらいのコードを調べてトラバースする必要がありますか？ 同じことがtry-catchにも当てはまります。

何がプログラマーを止めることができますか？ 関数が実際にエラーを処理する必要がない場合もあります。 ユーザーまたはシステム管理者がエラーを解決したり、回避策を見つけたりできるように、エラーをUIに渡したいだけです。

関数が例外を処理したくない場合は、try-catchブロックを使用しないため、前の呼び出し元が例外を処理できます。 構文に問題はないと思います。 それはまたはるかにきれいです。 ただし、パフォーマンスとその言語での実装方法は異なります。

以下に示すように、エラーを処理しないために4行のコードを追加する必要があります。

func myFunc1() error{
  // ...
  if (err){
      return err
  }
  return nil
}

エラーを呼び出し元に返して処理したい場合は、それで問題ありません。 重要なのは、エラーが返された時点で、そうしていることが見えるということです。

検討：

x, err := lib.SomeFunc(100, 4)
if err != nil {
  // A
}
// B

コードを見ると、関数の呼び出し時にエラーが発生する可能性があることがわかります。 エラーが発生した場合、コードフローはポイントAで終了します。他の場所のコードフローはポイントBであることがわかります。また、errがnilの場合、xは有効な値であるという暗黙のコントラクトもあります。ゼロまたはそれ以外の場合。

Javaとの対比：

x = SomeFunc(100, 4)

コードを見ても、関数が呼び出されたときにエラーが発生する可能性があるかどうかはわかりません。 エラーが発生して例外として表現された場合、 gotoが発生し、周囲のコードの下部に到達する可能性があります...または、例外がキャッチされない場合は、最終的に発生する可能性がありますコードのまったく異なる部分の下部のどこかにあります。 または、他の誰かのコードになってしまう可能性があります。 実際、デフォルトの例外ハンドラーは置き換えることができるため、他の誰かのコードによって行われたことに基づいて、文字通りどこにでも到達する可能性があります。

さらに、xが有効であるという暗黙の契約はありません。関数がnullを返し、エラーや値の欠落を示すのが一般的です。

Javaでは、これらの問題はすべての呼び出しで発生する可能性があります。悪いコードだけでなく、_all_Javaコードでも心配する必要があります。 そのため、Java開発環境には、ポイントしている関数が例外を引き起こす可能性があるかどうか、およびそれが引き起こす可能性のある例外を示すポップアップヘルプがあります。 Javaがチェック例外を追加したのはそのためです。そのため、一般的なエラーについては、関数呼び出しによって例外が発生し、プログラムフローが迂回される可能性があることを少なくとも警告する必要がありました。 一方、返されたnullとNullPointerExceptionのチェックされていない性質は、コストが明示的にラップする必要がある場合でも、Java 8にOptionalクラスを追加してJava8を改善しようとするほどの問題です。オブジェクトを返すすべての関数の戻り値。

私の経験では、渡された予期しないnull値からのNullPointerExceptionは、Javaコードがクラッシュする最も一般的な方法であり、通常、ほとんど完全に役に立たない大きなバックトレースが発生します。障害のあるコードから遠く離れて生成されたため、原因を示さないエラーメッセージ。 Goでは、Goの経験がはるかに少ないにもかかわらず、正直なところ、nil逆参照パニックが重大な問題であるとは思っていません。 それは、私にとって、Javaはその逆ではなくGoから学ぶべきであることを示しています。

構文に問題はないと思います。

構文がJavaスタイルの例外の問題だと言っている人はいないと思います。

@ lpar 、Goでのnil逆参照パニックが、JavaでのNullPointerExceptionよりも優れているのはなぜですか？ 「パニック」と「スロー」の違いは何ですか？ それらのセマンティクスの違いは何ですか？

パニックは回復可能であり、スローはキャッチ可能ですか？ 右？

私はちょうど1つの違いを思い出しました、パニックであなたはエラーオブジェクトまたは文字列オブジェクトまたは他のタイプのオブジェクトでパニックになることができます（私が間違っているなら私を訂正してください）が、throwであなたはタイプExceptionまたはサブクラスのオブジェクトを投げることができます例外のみ。

Goでのnil逆参照パニックが、JavaでのNullPointerExceptionよりも優れているのはなぜですか？

前者は私の経験ではほとんど起こらないのに対し、後者はいつも起こるので、私が説明した理由で。

@lpar最近Javaでプログラミングしていないので、これは新しいことだと思います（過去5年間）が、C＃には、例外を作成するためのnull参照を回避するための安全なナビゲーション演算子がありますが、Goには何がありますか？ よくわかりませんが、そのような状況に対処するものは何もないと思います。 したがって、パニックを回避したい場合でも、これらの醜いネストされたif-not-nil-elseステートメントをコードに追加する必要があります。

エラーの戻り値を確認する限り、通常、戻り値を確認してGoでnilであるかどうかを確認する必要はありません。 したがって、醜いネストされたifステートメントはありません。

ヌル逆参照は悪い例でした。 あなたがそれを捕まえなければ、GoとJavaはまったく同じように機能します-スタックトレースでクラッシュします。 スタックトレースが役に立たないのはどうしてですか。 あなたはそれが起こった正確な場所を知っています。 私の経験では、null逆参照は単純なプログラマーのエラーが原因であるため、C＃とGo for meの両方で、この種のクラッシュを修正するのは通常簡単です。 この特定のケースでは、誰からも学ぶことは何もありません。

@lpar

前者は私の経験ではほとんど起こらないのに対し、後者はいつも起こるので、私が説明した理由で。

これは偶然であり、JavaがGoよりもnil / nullの方がどういうわけか悪いという理由はコメントにありませんでした。 Goコードで多数のnil逆参照クラッシュが発生しました。 これらは、C＃/ Javaのnull逆参照とまったく同じです。 Goでより多くの値型を使用している可能性があります。これは役立ちますが（C＃にもあります）、何も変更されません。

例外として、Swiftを見てみましょう。 エラーをスローする可能性のある関数のキーワードthrowsがあります。 それなしで機能することはできません。 実装に関しては、returnのように機能します。おそらく、一部のレジスタはエラーを返すために予約されており、関数をスローするたびに通常どおりに戻りますが、エラー値が含まれます。 したがって、予期しないエラーの問題が解決されました。 どの関数がスローされるかを正確に知っており、それが発生する可能性のある正確な場所を知っています。 エラーは値であり、スタックの巻き戻しは必要ありません。 あなたがそれを捕まえるまで、彼らはただ返されます。

または、結果とエラーを運ぶ特別な結果タイプがあるRustに似たもの。 エラーは、明示的な条件ステートメントなしで伝播できます。 それに加えて、パターンマッチングの良さもたくさんありますが、それはおそらくGoには当てはまりません。

これらの言語は両方とも、両方のソリューション（CとJava）を採用し、それらを組み合わせてより優れたものにします。 例外からのエラー伝播+エラー値とCからの明らかなコードフロー+何も役に立たない醜いボイラープレートコードはありません。 したがって、これらの特定の実装を検討し、何らかの形で例外に似ているという理由だけで完全に無効にしないことが賢明だと思います。 例外が非常に多くの言語で使用されているのには理由があります。例外にはプラス面があるからです。 そうでなければ、言語はそれらを無視します。 特にC ++の後。

スタックトレースが役に立たないのはどうしてですか。

私は「ほとんど完全に役に立たない」と言いました。 のように、私はそれから1行の情報しか必要としませんが、それは数十行の長さです。

これは偶然であり、JavaがGoよりもnil / nullの方がどういうわけか悪いという理由はコメントにありませんでした。

その後、あなたは聞いていません。 戻って、暗黙の契約に関する部分を読んでください。

エラーは、明示的な条件ステートメントなしで伝播できます。

そして、それがまさに問題です。エラーが伝播し、制御フローが変化し、それが発生することを示す明示的なものは何もありません。 どうやらあなたはそれが問題だとは思わないが、他の人は同意しない。

RustまたはSwiftによって実装された例外が、私が知らないJavaと同じ問題に苦しんでいるかどうかにかかわらず、問題の言語に精通した誰かにそれを任せます。

@KamyarM基本的にnilを

https://fsharpforfunandprofit.com/posts/the-option-type/

そして、それがまさに問題です。エラーが伝播し、制御フローが変化し、それが発生することを示す明示的なものは何もありません。

これは私に当てはまります。 別のパッケージを消費するパッケージを開発し、そのパッケージが例外をスローした場合、その機能を使用するかどうかに関係なく、_I_もそのことを認識している必要があります。 これは、提案されている言語機能の中で珍しい側面です。 ほとんどは、プログラマーがオプトインできるもの、または自分の裁量で使用しないものです。 例外は、その意図により、予想されるかどうかにかかわらず、あらゆる種類の境界を越えます。

私は「ほとんど完全に役に立たない」と言いました。 のように、私はそれから1行の情報しか必要としませんが、それは数十行の長さです。

そして、何百ものゴルーチンを含む巨大なGoトレースは、どういうわけかもっと便利ですか？ これでどこに行くのかわかりません。 ここでは、JavaとGoはまったく同じです。 また、フルスタックを観察して、コードがクラッシュした場所でどのように終了したかを理解すると便利な場合があります。 C＃とGoのトレースは、それを何度も助けてくれました。

その後、あなたは聞いていません。 戻って、暗黙の契約に関する部分を読んでください。

私はそれを読みました、何も変わりませんでした。 私の経験では、それは問題ではありません。 これが、両方の言語でのドキュメントの目的です（たとえば、 net.ParseIP ）。 値がnil / nullであるかどうかを確認するのを忘れた場合は、両方の言語でまったく同じ問題が発生します。 ほとんどの場合、Goはエラーを返し、C＃は例外をスローするため、nilについて心配する必要はありません。 優れたAPIは、例外や何が問題なのかを示す何かをスローせずにnullを返すだけではありません。 それ以外の場合は、明示的にチェックします。 私の経験でnullが発生する最も一般的なタイプのエラーは、各フィールドがポインタ/オブジェクトであるプロトコルバッファがある場合、または内部状態に応じてクラス/構造体フィールドがnilになる可能性がある内部ロジックがあり、前にチェックするのを忘れた場合です。アクセス。 これは私にとって最も一般的なパターンであり、Goではこの問題を大幅に軽減するものはありません。 少し役立つ2つの名前を付けることができます-便利な空の値と値の型です。 ただし、使用する前にすべての変数を作成する必要がないため、プログラミングのしやすさが重要になります。

そして、それがまさに問題です。エラーが伝播し、制御フローが変化し、それが発生することを示す明示的なものは何もありません。 どうやらあなたはそれが問題だとは思わないが、他の人は同意しない。

これは問題です。他のことを言ったことはありませんが、ここの人々はJava / C＃/ C ++の例外に固執しているため、少し似ているものはすべて無視します。 Swiftで関数にthrowsマークを付ける必要があるのは、関数に何を期待すべきか、制御フローがどこで壊れるか、Rustで使用するかを正確に確認できる理由です。 さまざまなヘルパーメソッドを使用してエラーを明示的に伝播し、より多くのコンテキストを提供します。 どちらも値と同じエラーの概念を使用しますが、ボイラープレートを減らすために構文糖衣でラップします。

そして、何百ものゴルーチンを含む巨大なGoトレースは、どういうわけかもっと便利ですか？

Goを使用すると、エラーが検出された時点の場所とともにエラーをログに記録することで、エラーに対処できます。 追加することを選択しない限り、バックトレースはありません。 私は一度だけそれをする必要がありました。

私の経験では、それは問題ではありません。

ええと、私の経験は異なります。ほとんどの人の経験は異なると思います。その証拠として、Java8がオプション型を追加したという事実を引用します。

このスレッドでは、例外の有無についての説明を含め、Goとそのエラー処理システムの多くの長所と短所について説明しました。これを読むことを強くお勧めします。

https://elixirforum.com/t/discussing-go-split-thread/13006/2

エラー処理に2セント（そのようなアイデアが上記で言及されていた場合は申し訳ありません）。

ほとんどの場合、エラーを再スローしたいと思います。 これにより、次のようなスニペットが作成されます。

a, err := fn()
if err != nil {
    return err
}
use(a)
return nil

変数に割り当てられていない場合（余分な構文なしで）、nil以外のエラーを自動的に再スローしましょう。 上記のコードは次のようになります。

a := fn()
use(a)

// or just

use(fn())

コンパイラが保存されますerr暗黙的に（見えない）変数、のためにそれを確認するためにnil終わりと進む（ERR == nilの場合）または（ERR！= nilの場合）それを返すと、戻りはnil通常のように、しかし自動的かつ暗黙的に、関数の実行中にエラーが発生しなかった場合の関数の。

err処理する必要がある場合は、明示的な変数に割り当てて使用する必要があります。

a, err := fn()
if err != nil {
    doSomething(err)
} else {
    use(a)
}
return nil

エラーは次のように抑制できます。

a, _ := fn()
use(a)

複数のエラーが返されるまれな（素晴らしい）ケースでは、明示的なエラー処理が必須になります（今のように）：

err1, err2 := fn2()
if err1 != nil || err2 != nil {
    return err1, err2
}
return nil, nil

それは私の主張でもあります-ほとんどの場合、エラーを再スローしたいのですが、これは通常デフォルトのケースです。 そして多分それにいくつかのコンテキストを与えます。 例外を除いて、コンテキストはスタックトレースによって自動的に追加されます。 Goのようなエラーの場合は、エラーメッセージを追加して手動で行います。 もっとシンプルにしてみませんか。 そしてそれは、他の言語が明快さの問題とバランスを取りながらやろうとしていることです。

したがって、「変数に割り当てられていない場合（追加の構文なしで）、nil以外のエラーを自動的に再スローする」ことに同意しますが、後半の部分でバグが発生します。 それが例外を除いた問題の根源であり、なぜ人々は彼らにわずかに関連することについて話すことに反対しているのだと思います。 これらは、余分な構文なしで制御フローを変更します。 それは悪いことです。

たとえば、Swiftを見ると、このコードはコンパイルされません。

func a() throws {}
func b() throws {
  a()
}

aはエラーをスローする可能性があるため、エラーを伝播するためにもtry a()を書き込む必要があります。 あなたが削除するとthrowsからbそれがさえてコンパイルされませんtry a() 。 b内でエラーを処理する必要があります。 これは、例外の不明確な制御フローの問題とObjective-Cエラーの冗長性の両方を解決する、エラーを処理するためのはるかに優れた方法です。 後者は、Goのエラーとほぼ同じであり、Swiftが置き換えることを意図しています。 私が嫌いなのは、Swiftも使用しているtry, catchものです。 戻り値の一部としてエラーを残したいと思います。

したがって、私が提案するのは、実際に追加の構文を使用することです。 呼び出しサイトがそれ自体で、制御フローが変更される可能性のある潜在的な場所であることを通知するようにします。 また、この余分な構文を記述しないと、コンパイルエラーが発生することも提案します。 これは、Goが現在どのように機能するかとは異なり、エラーを処理することを強制します。 _ようなものでエラーをサイレントにする機能を投入することができます。これは、小さなエラーをすべて処理するのが非常にイライラする場合があるためです。 たとえば、 printf 。 何かを記録できなくてもかまいません。 Goにはすでにこれらの厄介なインポートがあります。 しかし、それは少なくともツールで解決しました。

私が今考えることができるコンパイル時エラーには2つの選択肢があります。 Go nowのように、エラーを黙って無視します。 私はそれが好きではありません、そしてそれは常にGoエラー処理に関する私の問題でした。 何も強制されません。デフォルトの動作では、エラーを黙って無視します。 それは悪いことです、それはあなたが頑強でデバッグしやすいプログラムを書く方法ではありません。 私が怠惰であるか時間切れであるときにObjective-Cであまりにも多くのケースがあり、同じコードのバグにぶつかっただけでエラーを無視しましたが、なぜそれが起こったのかについての診断情報はありませんでした。 少なくともログを記録することで、多くの場合、その場で問題を解決することができます。

欠点は、人々がエラーを無視し始め、いわばどこにでもtry, catch(...)配置する可能性があることです。 それは可能性ですが、同時に、デフォルトでエラーが無視されるので、そうするのはさらに簡単です。 例外についての議論はここでは当てはまらないと思います。 例外を除いて、何人かの人々が達成しようとしているのは、彼らのプログラムがより安定しているという幻想です。 未処理の例外がプログラムをクラッシュさせるという事実がここでの問題です。

他の選択肢はパニックになるでしょう。 しかし、それはただイライラするだけで、例外の記憶をもたらします。 それは間違いなく人々を彼らのプログラムがクラッシュしないように「防御的な」コーディングをするように導くでしょう。 私にとって、現代語はコンパイル時に可能な限り多くのことを行い、実行時に可能な限り少ない決定を残す必要があります。 パニックが適切である可能性があるのは、コールスタックの最上位です。 たとえば、main関数でエラーを処理しないと、自動的にパニックが発生します。 これはゴルーチンにも当てはまりますか？ おそらくすべきではありません。

なぜ妥協を検討するのですか？

@ nick-korsakov元の提案（この問題）は、エラーにコンテキストを追加したいと考えています。

エラーを無視することはすでに簡単です（おそらく簡単すぎます）（＃20803を参照）。 エラー処理に関する既存の提案の多くは、変更せずにエラーを返すのを容易にします（たとえば、＃16225、＃18721、＃21146、＃21155）。 追加情報を使用してエラーを簡単に返すことができるものはほとんどありません。

このコメントも参照してください。

このコメントでは、（ループで実行するのではなく）この議論を進めるために、慎重に処理されたエラーメッセージなどの目標をより適切に定義する必要があることをお勧めします。 全体を読むのはかなり興味深いですが、3秒間の金魚の記憶の問題の影響を受けているようです（あまり焦点を絞っていない/前進していない、素晴らしい創造的な構文の変更を繰り返している、例外/パニックなどについての議論）。

別の自転車小屋：

func makeFile(url string) (size int, err error){
    rsp, err := http.Get(url)
    try err
    defer rsp.Body.Close()

    var data dataStruct
    dec := json.NewDecoder(rsp.Body)
    err := dec.Decode(&data)
    try errors.Errorf("could not decode %s: %v", url, err)

    f, err := os.Create(data.Path)
    try errors.Errorf("could not open file %s: %v", data.Path, err)
    defer f.Close()

    return f.Write([]byte(data.Rows))
}

tryは、「空の値でない場合は返す」ことを意味します。 これでは、errがnilの場合、 errors.Errorfがnilを返すと想定しています。 これは、簡単なラッピングを目標にしながら、期待できるほどの節約になると思います。

オプションタイプが正しいアイデアであるのはなぜですか？

標準ライブラリのスキャナータイプは、構造内にエラー状態を格納します。構造のメソッドは、続行する前にエラーの存在を責任を持ってチェックできます。

type Scanner struct{
    err error
}
func (s *Scanner) Scan() bool{
   if s.err != nil{
       return false
   }
   // scanning logic
}
func (s *Scanner) Err() error{ return s.err }

タイプを使用してエラー状態を格納することにより、そのようなタイプを使用するコードに冗長なエラーチェックがないようにすることができます。

また、言語での創造的で奇妙な構文の変更や予期しない制御の転送も必要ありません。

また、try / catchのようなものを提案する必要があります。ここで、errはtry {}内で定義され、errがnil以外の値に設定されている場合、フローはtry {}からerrハンドラーブロック（存在する場合）にブレークします。

内部的には例外はありませんが、全体を近づける必要があります
errを割り当てることができるすべての行の後にif err != nil breakチェックを実行する構文に。
例えば：

...
try(err) {
   err = doSomethig()
   err, value := doSomethingElse()
   doSomethingObliviousToErr()
   err = thirdErrorProneThing()
} 
catch(err SomeErrorType) {
   handleSomeSpecificErr(err)
}
catch(err Error) {
  panic(err)
}

私はそれがC ++のように見えることを知っていますが、すべての行の後に手動のif err != nil {...}よりもよく知られていてきれいです。

@なので

スキャナータイプは、すべての作業を実行しているため機能します。したがって、途中で自身のエラーを追跡する余裕があります。 これが普遍的な解決策であると自分自身をからかってはいけません。

@carlmjohnson

単純なエラーに対して1つのライナーを処理する必要がある場合は、構文を変更して、returnステートメントが1行のブロックの先頭になるようにすることができます。
それは人々が書くことを可能にするでしょう：

func makeFile(url string) (size int, err error){
    rsp, err := http.Get(url)
    if err != nil return err
    defer rsp.Body.Close()

    var data dataStruct
    dec := json.NewDecoder(rsp.Body)
    err := dec.Decode(&data)
    if err != nil return errors.Errorf("could not decode %s: %v", url, err)

    f, err := os.Create(data.Path)
    if err != nil return errors.Errorf("could not open file %s: %v", data.Path, err)
    defer f.Close()

    return f.Write([]byte(data.Rows))
}

スペックを次のように変更する必要があると思います（これはかなりナイーブかもしれません:)）

Block = "{" StatementList "}" | "return" Expression .

errが3行ではなく1行をチェックする場合、gofmtを単純に変更するよりも、特別なケーシングリターンの方が本当に優れているとは思いません。

@urandom

1つのボックス化可能なタイプを超えて合体するエラーとそのアクションは推奨されるべきではありません。 私にとっては、関係のないさまざまなアクションから発生したエラー間でエラーコンテキストをラップまたは追加する努力が不足していることを示しています。

スキャナーのアプローチは、この「エラーは価値観」というマントラ全体の文脈で私が読んだ最悪のことの1つです。

1. ボイラープレートの処理で多くのエラーを必要とするほとんどすべてのユースケースでは役に立ちません。 複数の外部パッケージを呼び出す関数は、その恩恵を受けません。
2. それは複雑でなじみのない概念です。 これを導入すると、将来の読者を混乱させ、コードを必要以上に複雑にして、言語設計の欠陥を回避できるようになります。
3. ロジックを隠し、メリットを享受せずに最悪の事態（複雑な制御フロー）を取り除くことで、例外と同様にしようとします。
4. 場合によっては、コンピューティングリソースを浪費します。 すべての呼び出しは、何年も前に行われた無駄なエラーチェックに時間を浪費する必要があります。
5. エラーが発生した正確な場所を非表示にします。 あるファイル形式を解析またはシリアル化する場合を想像してみてください。 読み取り/書き込み呼び出しのチェーンがあります。 最初のものが失敗したと想像してください。 エラーが発生した正確な場所をどのように判断しますか？ 解析またはシリアル化したフィールドはどれですか？ 「IOエラー」、「タイムアウト」-この場合、これらのエラーは役に立ちません。 各読み取り/書き込みにコンテキストを提供できます（たとえば、フィールド名）。 しかし、この時点では、アプローチ全体があなたに不利に働いているので、あきらめたほうがよいでしょう。

場合によっては、コンピューティングリソースを浪費します。

ベンチマーク？ 「計算リソース」とは正確には何ですか？

エラーが発生した正確な場所を非表示にします。

いいえ、そうではありません。nil以外のエラーは上書きされないためです。

複数の外部パッケージを呼び出す関数は、その恩恵を受けません。
それは複雑でなじみのない概念です
スキャナーのアプローチは、この「エラーは価値観」全体の文脈で私が読んだ最悪のことの1つです。

私の印象では、あなたはアプローチを理解していません。 これは、自己完結型の通常のエラーチェックと論理的に同等です。例を詳しく調べて、_読んだ_最悪のことではなく、理解できる最悪のことになる可能性があることをお勧めします。

申し訳ありませんが、私自身の提案を山に追加します。 私はここにあるもののほとんどを読み通しました、そして私はいくつかの提案が好きですが、彼らがやりすぎだと感じています。 問題はエラーボイラープレートです。 私の提案は、構文レベルでその定型文を排除し、エラーが渡される方法をそのままにしておくことです。

提案

_!トークンをシンタックスシュガーとして使用できるようにすることでエラーボイラープレートを減らし、ゼロ以外のerror値が割り当てられたときにパニックを引き起こします

val, err := something.MayError()
if err != nil {
    panic(err)
}

になる可能性があります

val, _! := something.MayError()

と

if err := something.MayError(); err != nil {
    panic(err)
}

になる可能性があります

_! = something.MayError()

もちろん、特定のシンボルは議論の余地があります。 _^ 、 _* 、 @なども検討しました。 一目で最も馴染みがあると思ったので、事実上の提案として_!を選びました。

構文的には、 _! （または選択されたトークン）は、それが使用されるスコープで使用可能なタイプerrorシンボルになります。 それはnilとして始まり、割り当てられるたびにnilチェックが実行されます。 nil以外のerror値に設定されている場合、パニックが開始されます。 _! （または選択したトークン）はgoで構文的に有効な識別子ではないため、名前の衝突は問題になりません。 このエーテル変数は、名前付きの戻り値と同様に、それが使用されるスコープにのみ導入されます。 構文的に有効な識別子が必要な場合は、コンパイル時に一意の名前に書き換えられるプレースホルダーを使用できます。

正当化

私が見ている最も一般的な批判の1つは、エラー処理の冗長性です。 API境界でのエラーは悪いことではありません。 ただし、特に再帰的なアルゴリズムの場合、API境界にエラーを発生させる必要があるのは面倒です。 再帰コードに導入される追加の冗長性エラーの伝播を回避するために、パニックを使用できます。 これはかなり一般的に使用されている手法だと思います。 私はそれを自分のコードで使用しましたが、goのパーサーを含む実際のコードで使用されているのを見ました。 プログラムの他の場所で検証を行い、エラーがゼロになることを期待している場合があります。 nil以外のエラーを受け取った場合、これは不変条件に違反します。 不変条件に違反した場合、パニックに陥ることは許容されます。 複雑な初期化コードでは、エラーをパニックに変えて回復し、コンテキストの知識が豊富な場所に返されるようにすることが理にかなっている場合があります。 これらすべてのシナリオで、エラーの定型文を減らす機会があります。

パニックをできるだけ避けることがgoの哲学だと思います。 これらは、APIの境界を越えてエラーを伝播するためのツールではありません。 ただし、これらは言語の機能であり、上記のような正当なユースケースがあります。 パニックは、プライベートコードでのエラーの伝播を単純化するための素晴らしい方法であり、構文を単純化することで、コードをよりクリーンで、間違いなくより明確にすることができます。 「if-error-panic」フォームよりも、一目で_! （または@ 、または `_ ^など）を認識しやすいと思います。 トークンを使用すると、伝達/理解するために記述/読み取りする必要のあるコードの量を大幅に減らすことができます。

1. エラーが発生する可能性があります
2. エラーがある場合、私たちはそれを期待していません
3. エラーがある場合は、おそらくチェーンの上位で処理されています

他の構文機能と同様に、悪用される可能性があります。 この場合、goコミュニティには、パニックに対処するための一連のベストプラクティスがすでにあります。 この構文の追加はパニックの構文糖衣であるため、その一連のベストプラクティスをその使用に適用できます。

パニックの許容可能なユースケースの簡素化に加えて、これにより、ラピッドプロトタイピングが容易になります。 コードを書き留めたいと思っていて、おもちゃで遊んでいるときにエラーでプログラムをクラッシュさせたい場合は、「if-error-panic」形式ではなく、この構文の追加を利用できます。 開発の初期段階で自分自身をより少ない行で表現できれば、自分のアイデアをより早くコードに取り入れることができます。 コードの完全なアイデアが得られたら、戻ってコードをリファクタリングし、適切な境界でエラーを返します。 本番コードに無料のパニックを残すことはしませんが、強力な開発ツールになる可能性があります。

パニックは別の名前による単なる例外であり、Goについて私が気に入っていることの1つは、例外が例外的であるということです。 構文糖衣を与えることによって、これ以上の例外を奨励したくありません。

@carlmjohnson次の2つのうちの1つが当てはまる必要があります。

1. パニックは、正当なユースケースを持つ言語の一部です。
2. パニックには正当なユースケースがないため、言語から削除する必要があります

答えは1だと思います。
また、「パニックは別の名前による単なる例外である」ということにも同意しません。 こういう手振りは本当の議論を妨げると思います。 他のほとんどの言語で見られるように、パニックと例外の間には重要な違いがあります。

ひざまずく「パニックは悪い」という反応は理解していますが、パニックの使用に対する個人的な感情は、パニックが使用されているという事実を変えることはなく、実際に役立ちます。 goコンパイラは、パニックを使用して、パーサーと型チェックフェーズ（最後に調べたフェーズ）の両方で、深く再帰的なプロセスを回避します。
それらを使用して、深く再帰的なコードを介してエラーを伝播することは、許容できる使用法であるだけでなく、go開発者によって承認された使用法のようです。

パニックは特定の何かを伝えます：

ここで何かがうまくいかなかったので、ここで処理する準備ができていませんでした

コードには、それが当てはまる場所が常にあります。 特に開発の初期段階。 Goは、以前のリファクタリングエクスペリエンスを改善するために変更されました：タイプエイリアスの追加。 ソースに近いレベルでエラーを処理できるかどうか、またどのように処理するかを具体化できるまで、パニックを伴う不要なエラーを伝播できると、コードの記述と段階的なリファクタリングの冗長性が大幅に低下します。

ここでのほとんどの提案は、言語の大幅な変更を提案しているように感じます。 これは私が思いついた最も透明なアプローチです。 これにより、現在のエラー処理の認知モデル全体をそのまま維持しながら、特定の、しかし一般的なケースの構文を減らすことができます。 現在のベストプラクティスでは、「goコードはAPIの境界を越えてパニックにならないようにする必要があります」と規定されています。 パッケージにパブリックメソッドがある場合、エラーが回復できないまれな場合（たとえば、不変の違反）を除いて、問題が発生した場合にエラーを返す必要があります。 この言語への追加は、そのベストプラクティスに取って代わるものではありません。 これは、内部コードの定型文を減らし、スケッチのアイデアをより明確にする方法にすぎません。 それは確かにコードを直線的に読みやすくします。

var1, _! := trySomeTask1()
var2, _! := trySomeTask2(var1)
var3, _! := trySomeTask3(var2)
var4, _! := trySomeTask4(var3)

よりもはるかに読みやすい

var1, err := trySomeTask1()
if err != nil {
    panic(err)
}
var2, err := trySomeTask2(var1)
if err != nil {
    panic(err)
}
var3, err := trySomeTask3(var2)
if err != nil {
    panic(err)
}
var4, err := trySomeTask4(var3)
if err != nil {
    panic(err)
}

構文とオブジェクト階層の欠如（Goには継承がないため、これは理にかなっています）を除けば、GoのパニックとJavaやPythonなどの例外の間に基本的な違いはありません。 それらがどのように機能し、どのように使用されるかは同じです。

もちろん、パニックは言語の正当な場所を持っています。 パニックは、他の方法では回復できないプログラマーのエラーが原因でのみ発生するはずのエラーを処理するためのものです。 たとえば、整数のコンテキストでゼロで除算した場合、可能な戻り値はなく、最初にゼロをチェックしないのはあなた自身の責任であるため、パニックになります。 同様に、範囲外のスライスを読み取る場合は、値としてnilを使用してみてください。これらは、ネットワークがダウンしている、ファイルのアクセス許可が悪いなどの予期された状態ではなく、プログラマーのエラーが原因であるため、パニックに陥ります。スタックを爆破します。 Goは、テンプレートのようにパニックになるいくつかのヘルパー関数を提供します。これらは、プログラマーのエラーによってエラーが発生する必要があるハードコードされた文字列で使用されることが予想されるためです。 メモリ不足はそれ自体がプログラマーの障害ではありませんが、回復不能であり、どこでも発生する可能性があるため、エラーではなくパニックになります。

スタックを短絡する方法としてパニックを使用することもありますが、読みやすさとパフォーマンスの理由から一般的に眉をひそめています。Goがその使用を奨励するために変更される可能性はありません。

パニックに陥り、Javaのチェックされていない例外はほとんど同じであり、同じ理由で同じユースケースを処理するために存在します。 他の言語の例外と同じ問題があるため、他の場合にパニックを使用するように人々に勧めないでください。

スタックを短絡する方法としてパニックを使用することもありますが、読みやすさとパフォーマンスの理由から、一般的には眉をひそめています。

まず第一に、読みやすさの問題は、この構文の変更が直接対処するものです。

// clearly, linearly shows that these steps must occur in order,
// and any errors returned cause a panic, because this piece of
// code isn't responsible for reporting or handling possible failures:
// - IO Error: either network or disk read/write failed
// - External service error: some unexpected response from the external service
// - etc...
// It's not this code's responsibility to be aware of or handle those scenarios.
// That's perhaps the parent process's job.
var1, _! := trySomeTask1()
var2, _! := trySomeTask2(var1)
var3, _! := trySomeTask3(var2)
var4, _! := trySomeTask4(var3)

vs

var1, err := trySomeTask1()
if err != nil {
    panic(err)
}
var2, err := trySomeTask2(var1)
if err != nil {
    panic(err)
}
var3, err := trySomeTask3(var2)
if err != nil {
    panic(err)
}
var4, err := trySomeTask4(var3)
if err != nil {
    panic(err)
}

読みやすさはさておき、他の理由はパフォーマンスです。
はい、パニックと延期ステートメントを使用するとパフォーマンスが低下することは事実ですが、多くの場合、この違いは実行中の操作には無視できます。 ディスクとネットワークのIOは、平均して、遅延/パニックを管理するための潜在的なスタックマジックよりもはるかに長い時間がかかります。

パニックについて話し合うとき、この点がよく耳にしますが、パニックがパフォーマンスの低下であると言うのは不誠実だと思います。 確かに可能ですが、そうである必要はありません。 言語の他の多くのものと同じように。 パフォーマンスの低下が非常に重要となるタイトなループ内でパニックに陥っている場合は、そのループ内でも延期するべきではありません。 実際、それ自体がパニックを選択する関数は、通常、それ自体のパニックをキャッチするべきではありません。 同様に、今日作成されたgo関数は、エラーとパニックの両方を返すことはありません。 これは不明確で、ばかげており、ベストプラクティスではありません。 おそらく、Java、Python、Javascriptなどで使用される例外を確認するのに慣れているかもしれませんが、goコードでパニックが一般的に使用される方法ではなく、エラーを伝播する場合に特に演算子を追加することはないと思いますパニックを介してコールスタックを増やすと、人々がパニックを使用する方法が変わります。 彼らはとにかくパニックを使用しています。 この構文拡張のポイントは、開発者がパニックを使用しているという事実を認めることであり、完全に正当な使用法があり、その周りの定型文を減らします。

この構文機能によって可能になると思われる、現在は不可能である/ベストプラクティスに反する問題のあるコードの例をいくつか教えてください。 誰かがパニック/回復を介してコードのユーザーにエラーを伝えている場合、それは現在眉をひそめ、このような構文が追加されたとしても、明らかに継続します。 可能であれば、次のように答えてください。

1. このような構文拡張からどのような悪用が生じると思いますか？
2. var1, err := trySomeTask1(); if err != nil { panic(err) } 、 var1, _! := trySomeTask1()が伝えないことを何を伝えますか？ どうして？

あなたの議論の核心は「パニックはひどいので、私たちはそれらを使うべきではない」ということだと私には思えます。
それらが共有されていない場合、私はその背後にある理由を開梱して議論することはできません。

これらの原因は、ネットワークのダウンやファイルのアクセス許可の悪さなど、予期された状態ではなく、プログラマーのエラーが原因であるため、パニックに陥ってスタックが爆破されます。

私は、ほとんどのゴファーのように、値としてのエラーの考え方が好きです。 ドキュメントを見なくても、APIのどの部分が結果を保証し、どの部分が失敗する可能性があるかを明確に伝えるのに役立つと思います。

これにより、エラーの収集やエラーの詳細情報の拡張などが可能になります。 これはすべて、コードがユーザーコードと交差するAPI境界で非常に重要です。 ただし、これらのAPI境界内では、多くの

エラーを処理するのがコードの仕事ではない場合があります。
ライブラリを作成している場合、ネットワークスタックがダウンしているかどうかは関係ありません。これは、ライブラリ開発者としての私の制御の範囲外です。 これらのエラーをユーザーコードに戻します。

私自身のコードでも、エラーを親関数に返すことが唯一の仕事であるコードを書くことがあります。

たとえば、http.HandlerFuncが応答としてディスクからファイルを読み取ったとします。これはほとんどの場合機能します。失敗した場合は、プログラムが正しく書き込まれていないか（プログラマーエラー）、ファイルシステムに問題がある可能性があります。プログラムの責任範囲外。 http.HandlerFuncがパニックになると、それは終了し、一部のベースハンドラーがそのパニックをキャッチして、クライアントに500を書き込みます。 将来、そのエラーを別の方法で処理したい場合は、 _!をerr置き換えて、エラー値でやりたいことができます。 問題は、プログラムの存続期間中、私はおそらくそれをする必要はないだろうということです。 そのような問題が発生した場合、ハンドラーはそのエラーの処理を担当するコードの一部ではありません。

IO障害、ネットワーク障害などのために、ハンドラーにif err != nil { panic(err) }またはif err != nil { return ..., err }を書き込むことができ、通常はそうします。エラーをチェックする必要がある場合でも、それを行うことができます。 ただし、ほとんどの場合、私はif err != nil { panic(err) }書いているだけです。

または、別の例として、トライを再帰的に検索している場合（たとえば、httpルーターの実装で）、関数func (root *Node) Find(path string) (found Value, err error)宣言します。 その関数は、ツリーを下って生成されたパニックを回復する関数を延期します。 プログラムが不正な試行を作成している場合はどうなりますか？ プログラムが正しい権限を持つユーザーとして実行されていないために一部のIOが失敗した場合はどうなりますか？ これらの問題は、私のトライ検索アルゴリズムの問​​題ではありません-後で明示的にそうしない限り-しかし、それらは私が遭遇する可能性のあるエラーである可能性があります。 それらをスタックの一番上まで戻すと、スタック上で理想的にはいくつかのnilエラー値になるものを保持するなど、多くの余分な冗長性が生じます。 代わりに、そのパブリックAPI関数までエラーをパニックにして、ユーザーに返すことを選択できます。 現時点では、これでも余分な冗長性が発生しますが、必ずしもそうする必要はありません。

他の提案では、1つの戻り値を特別なものとして扱う方法について議論しています。 これは基本的に同じ考えですが、言語にすでに組み込まれている機能を使用する代わりに、特定の場合に言語の動作を変更しようとします。 実装のしやすさという点では、このタイプの提案（すでにサポートされているものの構文糖衣構文）が最も簡単になります。

編集して追加：
私は、私が書いた提案とは結婚していませんが、エラー処理の問題を新しい角度から見ることが重要だと思います。 誰もその小説を提案しているわけではないので、この問題の理解を再構築できるかどうかを確認したいと思います。 問題は、エラーが必要のないときに明示的に処理されている場所が多すぎることです。開発者は、追加の定型コードなしでエラーをスタックに伝播する方法を望んでいます。 Goにはすでにその機能があることがわかりましたが、そのための適切な構文はありません。 これは、動作を変更せずに言語をより冗長にするために、既存の機能をより冗長でない構文でラップすることについての説明です。 私たちがそれを達成できれば、それは勝利ではありませんか？

@mccolljrありがとうございますが、この提案の目標の1つは、エラー処理の3つのケースすべてを処理する新しい方法を開発するように人々を促すことです。エラーを無視し、変更せずにエラーを返し、追加のコンテキスト情報とともにエラーを返します。 あなたのパニック提案は3番目のケースに対処していません。 それは重要なものです。

@mccolljr APIの境界は、あなたが想定しているよりもはるかに一般的だと思います。 API内呼び出しは一般的なケースではありません。 どちらかといえば、それは逆かもしれません（いくつかのデータはここで興味深いでしょう）。 したがって、API内呼び出し用の特別な構文を開発することが正しい方向であるかどうかはわかりません。 さらに、API内でpanic return edエラーではなく、 panic edエラーには用途がありますが、明らかに優れている状況はまれに思われます。

パニックを介してコールスタックにエラーを伝播する場合に特に演算子を追加しても、人々がパニックを使用する方法が変わるとは思いません。

私はあなたが間違っていると思います。 それはとても便利なので、人々はあなたの速記者に手を差し伸べるでしょう、そしてそれから彼らは以前よりずっとパニックを使うことになります。

パニックが時々またはまれに役立つかどうか、およびAPIの境界を越えて、またはAPIの境界内で役立つかどうかは、赤ニシンです。 エラーに対して実行する可能性のあるアクションはたくさんあります。 あるアクションを他のアクションよりも優先することなく、エラー処理コードを短縮する方法を探しています。

しかし、多くの場合、この違いは実行されている操作には無視できます。

確かに、危険な道だと思います。 最初はごくわずかに見えますが、それは積み重なって、最終的にはすでに遅れているときにボトルネックを引き起こします。 最初からパフォーマンスを念頭に置いて、より良い解決策を見つけようとすべきだと思います。 すでに述べたように、SwiftとRustにはエラーの伝播がありますが、基本的には、単純なリターンを構文糖衣にラップして実装します。 はい、既存のソリューションを再利用するのは簡単ですが、基本的に例外であるという事実を隠そうとする見慣れない構文糖衣の背後に隠されたパニックを単純化して使用するように人々を促すよりも、すべてをそのままにしておくことをお勧めします。

最初はごくわずかに見えますが、それは積み重なって、最終的にはすでに遅れているときにボトルネックを引き起こします。

結構です。 架空のパフォーマンスのボトルネックは、幾何学的に無視できるパフォーマンスのボトルネックです。

結構です。 架空のパフォーマンスのボトルネックは、幾何学的に無視できるパフォーマンスのボトルネックです。

このトピックからあなたの個人的な感情を残してください。 あなたは明らかに私に問題があり、何か有用なものを持ち込みたくないので、私のコメントを無視して、以前のほとんどすべてのコメントで行ったように反対票を残してください。 これらの無意味な答えを投稿し続ける必要はありません。

私はあなたに問題はありません、あなたはそれを裏付けるデータなしでパフォーマンスのボトルネックについて主張しているだけです、そして私はそれを言葉と親指で指摘しています。

皆さん、会話を尊重し、話題にしてください。 この問題は、Goエラーの処理に関するものです。

https://golang.org/conduct

エラーを無視することは既存の_すでにカバーされていると想定しているので、「エラーを返す/追加のコンテキストを使用する」の部分をもう一度確認したいと思います。

文字列が続く可能性のある2語のキーワードを提案しています（オプション）。 それが2語のキーワードである理由は2つあります。 まず、本質的に不可解な演算子とは異なり、事前の知識があまりなくても、演算子が何をするのかを理解するのは簡単です。 「またはバブル」を選択したのは、エラーが割り当てられていないorという単語が、エラーがnilでない場合、ここで処理されていることをユーザーに示すことを期待しているためです。 一部のユーザーは既に関連付けますor他の言語（PerlやPython）からfalsy値を処理し、そして読書とdata := Foo() or ...無意識のうちにということを伝えるかもしれないdata使用できない場合はorステートメントのbubbleキーワードは比較的短いですが、何かが起きていること（スタック）をユーザーに示している可能性があります。 upという単語も適切かもしれませんが、 or up全体が十分に理解できるかどうかはわかりません。 最後に、すべてがキーワードです。何よりもまず読みやすいため、次にその動作を関数自体で記述できないためです（パニックを呼び出して、現在の関数をエスケープできる場合がありますが、そうすることはできます。自分を止めてください、他の誰かが回復しなければなりません）。

以下はエラー伝播専用であるため、エラーを返す関数でのみ使用でき、他の戻り引数のゼロ値は次のとおりです。

エラーを変更せずに返す場合：

func Worker(path string) ([]byte, error) {
    data := ioutil.ReadFile(path) or bubble

    return data;
}

追加のメッセージとともにエラーを返す場合：

func Worker(path string) ([]byte, error) {
    data := ioutil.ReadFile(path) or bubble fmt.Sprintf("reading file %s", path)

    modified := modifyData(data) or bubble "modifying the data"

    return data;
}

そして最後に、カスタマイズされたエラー修正のためのグローバルアダプタメカニズムを導入します。

// Default Bubble Processor
errors.BubbleProcessor(func(msg string, err error) error {
    return fmt.Errorf("%s: %v", msg, err)
})

// Some program might register the following:
errors.BubbleProcessor(func(msg string, err error) error {
    return errors.WithMessage(err, msg)
})

最後に、本当に複雑な処理が必要ないくつかの場所では、既存の冗長な方法がすでに最良の方法です。

面白い。 グローバルバブルハンドラーがあると、スタックトレースが必要な人に、トレースを呼び出す場所が与えられます。これは、このメソッドの優れた利点です。 OTOH、シグネチャfunc(string, error) errorがある場合、バブリングは組み込みのエラータイプで行われる必要があり、 error実装する具象タイプなどの他のタイプでは行われないことを意味します。

また、 or bubbleの存在は、 or dieまたはor panicの可能性を示唆しています。 それが機能なのかバグなのかわかりません。

本質的に不可解な演算子とは異なり、事前の知識があまりなくても、演算子が何をするのかを理解するのは簡単です。

あなたが最初にそれに遭遇したとき、それは良いかもしれません。 しかし、それを何度も読み書きする-それは冗長すぎるように見え、非常に単純なことを伝えるにはあまりにも多くのスペースを必要とします-スタックをバブルアップする未処理のエラー。 演算子は最初は不可解ですが、簡潔で、他のすべてのコードとは対照的です。 メインロジックは実際にはセパレータであるため、エラー処理から明確に分離されます。 一行にたくさんの単語があると、私の意見では読みやすさが損なわれます。 少なくともそれらをorbubbleマージするか、そのうちの1つを削除してください。 そこに2つのキーワードがある意味がわかりません。 それはGoを話し言葉に変えます、そしてそれがどうなるかを私たちは知っています（例えばVB）

私はグローバルアダプターのファンではありません。 私のパッケージがカスタムプロセッサを設定し、あなたのパッケージもカスタムプロセッサを設定している場合、誰が勝ちますか？

@ object88
デフォルトのロガーに似ていると思います。 （プログラムで）出力を設定するのは1回だけで、これは使用するすべてのパッケージに影響します。

エラー処理はロギングとは大きく異なります。 1つはプログラムの有益な出力を記述し、もう1つはプログラムのフローを管理します。 パッケージ内で論理フローを適切に管理する必要があることを行うようにアダプターをセットアップし、別のパッケージまたはプログラムがそれを変更した場合、あなたは悪い場所にいます。

トライキャッチファイナルをお持ち帰りください。もう戦いは必要ありません。 それはみんなを幸せにします。 他のプログラミング言語から機能や構文を借用することに何の問題もありません。 Javaがそれを行い、C＃もそれを行いました。どちらも、本当に成功したプログラミング言語です。 GOコミュニティ（または作成者）は、必要に応じて変更を受け入れてください。

@KamyarM 、私は敬意を表して同意しません。 try / catchはみんなを幸せにしません。 それをコードに実装したい場合でも、スローされた例外は、コードを使用するすべての人が例外を処理する必要があることを意味します。 これは、コードにローカライズできる言語の変更ではありません。

@ object88
実際、バブルプロセッサはプログラムの有益なエラー出力を記述しているように見え、ロガーとそれほど違いはありません。 また、アプリケーション全体で単一のエラー表現が必要であり、パッケージごとに異なることはないと思います。

簡単な例を提供できるかもしれませんが、私が見逃していることがあるかもしれません。

親指を立ててくれてありがとう。 それはまさに私が話している問題です。 GOコミュニティは変化に対してオープンではなく、私はそれを感じており、私はそれが本当に好きではありません。

これはおそらくこのケースとは関係ありませんが、C ++の三項演算子に相当するGoを別の日に探していたところ、この代替アプローチに出くわしました。

v：= map [bool] int {true：first_expression、false：second_expression} [条件]
単にではなく
v =状態？ first_expression：second_expression;

あなたたちが好む2つのフォームのどちらですか？ 上記の判読不能なコード（Go My Way）には、おそらく多くのパフォーマンスの問題がありますか、それともC ++（Highway）の2番目の単純な構文ですか？ 私は高速道路の人が好きです。 私はあなたのことを知りません。

要約すると、新しい構文を持ってきて、他のプログラミング言語から借りてください。 それは何も悪いことではありません。

よろしくお願いします、

GOコミュニティは変化に対してオープンではなく、私はそれを感じており、私はそれが本当に好きではありません。

これはあなたが経験していることの根底にある態度を誤解していると思います。 はい、誰かがtry / catchまたは？：を提案すると、コミュニティは多くの反発を生み出します。 しかし、その理由は、私たちが新しいアイデアに抵抗しているからではありません。 私たちはほとんどすべて、これらの機能を備えた言語を使用した経験があります。 私たちはそれらに非常に精通しており、私たちの誰かが何年もの間それらを日常的に使用しています。 私たちの抵抗は、これらが_古いアイデア_であり、新しいアイデアではないという事実に基づいています。 私たちはすでに変更を受け入れました：try / catchからの変更と？：の使用からの変更。 私たちが抵抗しているのは、私たちがすでに使用していて気に入らなかったものを使用するように_戻る_を変更することです。

実際、バブルプロセッサはプログラムの有益なエラー出力を記述しているように見え、ロガーとそれほど違いはありません。 また、アプリケーション全体で単一のエラー表現が必要であり、パッケージごとに異なることはないと思います。

誰かがバブリングを使用してスタックトレースを渡し、それを使用して決定を下したい場合はどうなりますか。 たとえば、エラーがファイル操作に起因する場合は失敗しますが、ネットワークに起因する場合は、待機してから再試行してください。 このためのロジックをエラーハンドラーに組み込むことはできましたが、ランタイムごとにエラーハンドラーが1つしかない場合は、競合のレシピになります。

@urandom 、これは些細な例かもしれませんが、私のアダプターがerrorを実装する別の構造体を返したとしましょう。これは、コードの他の場所で消費されると予想されます。 別のアダプターが付属してアダプターを置き換えると、コードが正しく機能しなくなります。

@KamyarM言語とそのイディオムは一緒になります。 エラー処理の変更を検討するときは、構文の変更だけでなく、（潜在的に）コードの構造そのものについても話します。

Try-catch-finallyは、このような非常に侵襲的な変更になります。これにより、Goプログラムの構造が根本的に変更されます。 対照的に、ここに表示される他の提案のほとんどは、各関数に対してローカルです。エラーは引き続き明示的に返される値であり、制御フローは非ローカルジャンプを回避します。

三項演算子の例を使用するには：はい、今日はマップを使用して偽の演算子を使用できますが、実際には本番コードでそれが見つからないことを願っています。 それはイディオムに従わない。 代わりに、通常は次のようなものが表示されます。

    var v int
    if condition {
        v = first_expression
    } else {
        v = second_expression
    }

構文を借用したくないということではなく、それが言語の残りの部分や今日すでに存在するコードの残りの部分にどのように適合するかを検討する必要があるということです。

@KamyarM私はGoとJavaの両方を使用していますが、Javaから例外処理をコピーすることをGoに強く望んでいません。 Javaが必要な場合は、Javaを使用してください。 そして、適切な問題、例えば＃23248に三項演算子の議論をしてください。

@lparですから、私が会社で働いていて、何らかの理由で彼らがプログラミング言語としてGoLangを選んだ場合、私は仕事を辞めてJavaに申し込む必要があります！？ 男に来て！

@bcmillsそこで提案したコードを数えることができます。 これは1行ではなく6行のコードだと思います。おそらく、コードの循環的複雑度のポイントが2つ得られます（皆さんはLinterを使用していますよね？）。

@carlmjohnsonと@bcmills古くて成熟した構文は、それが悪いことを意味するわけではありません。 実際、ifelse構文は三項演算子構文よりもはるかに古いと思います。

このGOイディオムのものを持ってきてよかったです。 それはこの言語の問題の1つにすぎないと思います。 変更のリクエストがあるときはいつでも、誰かがGoイディオムに反対だと言います。 私はそれを、変化に抵抗し、新しいアイデアを阻止するための単なる言い訳だと考えています。

@KamyarMは礼儀正しくしてください。 言語を小さく保つことの背後にある考え方について詳しく知りたい場合は、 https：//commandcenter.blogspot.com/2012/06/less-is-exponentially-more.htmlをお勧めし

また、try / catchの最近の議論とは関係のない一般的なコメント。

このスレッドには多くの提案があります。 自分自身で言えば、まだ解決すべき問題をしっかりと把握しているとは感じていません。 私はそれらについてもっと聞きたいです。

また、議論された問題の整理され要約されたリストを維持するという、うらやましいが重要なタスクを誰かが引き受けたいと思ったら、私は興奮します。

@josharian私はそこで率直に話していました。 言語やコミュニティで正確な問題を示したかったのです。 それをもっと批判として考えてください。 GoLangは批判を受けやすいですよね？

@KamyarMプログラミング言語にRustを選んだ会社で働いていた場合、Rust Githubにアクセスして、ガベージコレクションされたメモリ管理とC ++スタイルのポインターを要求し始めて、ボローチェッカーに対処する必要がなくなりますか？

GoプログラマーがJavaスタイルの例外を望まない理由は、それらに精通していないこととは何の関係もありません。 私は1988年にLispを介して最初に例外に遭遇しましたが、このスレッドにはもっと早く例外に遭遇した人がいると確信しています。アイデアは1970年代初頭にさかのぼります。

同じことが三項式にも当てはまります。 Goの歴史を読む-Goの作成者の1人であるKenThompsonは、1969年にベル研究所でB言語（Cの前身）で三項演算子を実装しました。 Goに含めるかどうか。

Goは批判を受けやすいですが、Goフォーラムでの議論は丁寧である必要があります。 率直であることは失礼であることと同じではありません。 https://golang.org/conductの「GopherValues」セクションを

@lparはい、Rustにそのようなフォーラムがある場合、私はそれを行います;-)真剣に私はそれを行います。 自分の声を聞きたいから。

@ianlancetaylor下品な言葉や言葉を使用しましたか？ 差別的な言葉や誰かのいじめ、または歓迎されない性的進歩を使用しましたか？ そうは思いません。
さあ、ここではGoプログラミング言語について話しているだけです。 宗教や政治などではありません。
率直でした。 自分の声が聞こえてほしかった。 そういうわけでこのフォーラムがあると思います。 声が聞こえるように。 あなたは私の提案や私の批判を気に入らないかもしれません。 それで大丈夫です。 しかし、私に話をさせて話し合う必要があると思います。そうしないと、すべてが完璧で問題がないため、さらに話し合う必要はないと結論付けることができます。

@josharian記事をありがとうございますそれを見ていきます。

さて、私は自分のコメントを振り返って、そこに何か悪いことがあるかどうかを確認しました。 私が侮辱したかもしれない唯一のもの（私はまだその批判をところで呼んでいます）はGoLangプログラミング言語イディオムです！ ははは！

私たちのトピックに戻るには、私の声が聞こえたら、GoAuthorsはTrycatchブロックを戻すことを検討してください。 プログラマーに任せて、適切な場所で使用するかどうかを決定してください（すでに似たようなものがあります。つまり、パニックが回復するのを延期し、プログラマーに馴染みのあるCatchを試してみませんか？）。
下位互換性のために、現在のGoエラー処理の回避策を提案しました。 それが最善の選択肢だと言っているわけではありませんが、実行可能だと思います。

私はこのトピックについてこれ以上議論することをやめます。

機会を下さりありがとうございます。

@KamyarMあなたは、あなたがあなたの議論に対する私たちの意見の相違で礼儀正しいままでいるという私たちの要求を混乱させています。 人々があなたに反対するとき、あなたは「親指を下ろしてくれてありがとう。それはまさに私が話している問題です。GOコミュニティは変化にオープンではなく、私はそれを感じます、そして私は本当にしません」のようなコメントで個人的な言葉で答えています。そんな感じだ」

もう一度：礼儀正しくしてください。 技術的な議論に固執する。 アイデアではなく人を攻撃する人身攻撃の議論は避けてください。 あなたが本物の私が何を意味するのか理解していないのなら、私はそれをオフラインで話し合うつもりです。 メールを送ってください。 ありがとう。

私は自分の2cを投入し、それが他のN 100のコメントで文字通り何かを繰り返していないことを願っています（またはurandomの提案の議論を踏んでいます）。

私は投稿された元のアイデアが好きですが、2つの主要な調整があります：

• 構文上のバイクシェディング：暗黙の制御フローを持つものはすべて、既存のオペレーターの過負荷ではなく、それ自体がオペレーターであるべきだと強く信じています。 ?!投げますが、Goの既存の演算子と簡単に混同されないものには満足しています。

• この演算子のRHSは、任意に挿入された値を持つ式ではなく、関数を取る必要があります。 これにより、開発者は、意図を明確にしながら、かなり簡潔なエラー処理コードを記述できるようになります。

func returnErrorf(s string, args ...interface{}) func(error) error {
  return func(err error) error {
    return errors.New(fmt.Sprintf(s, args...) + ": " + err.Error())
  }
}

func foo(r io.ReadCloser, callAfterClosing func() error, bs []byte) ([]byte, error) {
  // If r.Read fails, returns `nil, errors.New("reading from r: " + err.Error())`
  n := r.Read(bs) ?! returnErrorf("reading from r")
  bs = bs[:n]
  // If r.Close() fails, returns `nil, errors.New("closing r after reading [[bs's contents]]: " + err.Error())`
  r.Close() ?! returnErrorf("closing r after reading %q", string(bs))
  // Not that I advocate this inline-func approach, but...
  callAfterClosing() ?! func(err error) error { return errors.New("oh no!") }
  return bs, nil
}

エラーが発生しない場合はRHSを評価しないでください。そのため、このコードはクロージャーなどをハッピーパスに割り当てません。

このパターンを「オーバーロード」して、より興味深いケースで機能させることも非常に簡単です。 私は3つの例を念頭に置いています。

まず、RHSがfunc(error) (error, bool)場合、 returnを条件付きにすることができます（これを許可する場合は、無条件の戻り値とは異なる演算子を使用する必要があると思います。 ??使用しますが、私の「明確である限り気にしません」というステートメントは引き続き適用されます）：

func maybeReturnError(err error) (error, bool) {
  if err == io.EOF {
    return nil, false
  }
  return err, true
}

func id(err error) error { return err }

func ignoreError(err error) (error, bool) { return nil, false }

func foo(n int) error {
  // Does nothing
  id(io.EOF) ?? ignoreError
  // Still does nothing
  id(io.EOF) ?? maybeReturnError
  // Returns the given error
  id(errors.New("oh no")) ?? maybeReturnError
  return nil
}

または、次のように、外部関数の戻り型と一致する戻り型を持つRHS関数を受け入れることもできます。

func foo(r io.Reader) ([]int, error) {
  returnError := func(err error) ([]int, error) { return []int{0}, err }
  // returns `[]int{0}, err` on a Read failure
  n := r.Read(make([]byte, 4)) ?! returnError
  return []int{n}, nil
}

そして最後に、本当に必要な場合は、引数の型を変更することで、これを一般化して、単なるエラー以上のものを処理できます。

func returnOpFailed(name string) func(bool) error {
  return func(_ bool) error {
    return errors.New(name + " failed")
  }
}

func returnErrOpFailed(name string) func(error) error {
  return func(err error) error {
    return errors.New(name + " failed: " + err.Error())
  }
}

func foo(c chan int, readInt func() (int, error), d map[int]string) (string, error) {
  n := <-c ?! returnOpFailed("receiving from channel")
  m := readInt() ?! returnErrOpFailed("reading an int")
  result := d[n + m] ?! returnOpFailed("looking up the number")
  return result, nil
}

... map[string]interface{}手動でデコードするなど、ひどいことをしなければならないときに、個人的に本当に役立つと思います。

明確にするために、私は主に拡張機能を例として示しています。 それらのどれが（もしあれば）単純さ、明快さ、そして一般的な有用性の間で良いバランスをとっているのかわかりません。

エラーを無視することはすでに既存の_でカバーされていると想定しているので、「エラーを返す/追加のコンテキストを使用して」の部分をもう一度確認したいと思います。

文字列が続く可能性のある2語のキーワードを提案しています（オプション）。

@urandom提案の最初の部分は賛成です。いつでもそれから始めて、2番目の改訂のためにBubbleProcessorを残すことができます。 @ object88によって提起された懸念は有効なIMOです。 最近、「 httpのデフォルトのクライアント/トランスポートを上書きしないでください」などのアドバイスを目にしました。これは別のアドバイスになります。

このスレッドには多くの提案があります。 自分自身で言えば、まだ解決すべき問題をしっかりと把握しているとは感じていません。 私はそれらについてもっと聞きたいです。

また、議論された問題の整理され要約されたリストを維持するという、うらやましいが重要なタスクを誰かが引き受けたいと思ったら、私は興奮します。

@ianlancetaylorがあなたを任命している場合それはあなた@josharianだろうか？ ：blush：他の問題がどのように計画/議論されているのかわかりませんが、おそらくこの議論は「提案ボックス」として使用されているだけですか？

@KamyarM

@bcmillsそこで提案したコードを数えることができます。 これは1行ではなく6行のコードだと思います。おそらく、コードの循環的複雑度のポイントが2つ得られます（皆さんはLinterを使用していますよね？）。

循環的複雑度を非表示にすると見にくくなりますが、削除されません（ strlen覚えていますか？）。 エラー処理を「短縮」すると、エラー処理のセマンティクスが無視されやすくなりますが、見づらくなります。

フロー制御を再ルーティングするソース内のステートメントまたは式は、明白で簡潔である必要がありますが、それが明白であるか簡潔であるかの決定である場合、この場合は明白であることが優先されます。

このGOイディオムのものを持ってきてよかったです。 それはこの言語の問題の1つにすぎないと思います。 変更のリクエストがあるときはいつでも、誰かがGoイディオムに反対だと言います。 私はそれを、変化に抵抗し、新しいアイデアを阻止するための単なる言い訳だと考えています。

新しいものと有益なものには違いがあります。 あなたはアイデアを持っているので、その存在自体が承認に値すると思いますか？ 演習として、問題追跡システムを見て、コミュニティの考えに関係なく、すべてのアイデアが承認された場合は、今日のGoを想像してみてください。

おそらくあなたは自分のアイデアが他のアイデアよりも優れていると信じています。 そこで議論が始まります。イディオムのためにシステム全体がどのように壊れているかについて話すために会話を退化させる代わりに、批判に直接、ポイントごとに対処するか、あなたとあなたの仲間の間の中間点を見つけてください。

@ gdm85
返されたエラーの一部で、ある種のカスタマイズのためにプロセッサを追加しました。 また、デフォルトのロガーを使用するのと少し似ていると思いますが、ほとんどの場合は使用をやめることができますが、私は提案を受け入れると言っていました。 そして、記録として、デフォルトのロガーとデフォルトのhttpクライアントがリモートで同じカテゴリにあるとは思わない。

私は@gburgessivの提案も好きですが、私は不可解な演算子自体の大ファンではありません（Rustのように少なくとも?選ぶかもしれませんが、それでも不可解だと思います）。 これはもっと読みやすく見えますか？

func foo(r io.ReadCloser, callAfterClosing func() error, bs []byte) ([]byte, error) {
  // If r.Read fails, returns `nil, errors.New("reading from r: " + err.Error())`
  n := r.Read(bs) or returnErrorf("reading from r")
  bs = bs[:n]
  // If r.Close() fails, returns `nil, errors.New("closing r after reading [[bs's contents]]: " + err.Error())`
  r.Close() or returnErrorf("closing r after reading %q", string(bs))
  // Not that I advocate this inline-func approach, but...
  callAfterClosing() or func(err error) error { return errors.New("oh no!") }
  return bs, nil
}

そしてうまくいけば、彼の提案には、 errorsパッケージのどこかに彼のreturnErrorfに似た関数のデフォルトの実装も含まれるでしょう。 多分errors.Returnf() 。

@KamyarM
あなたはすでにここであなたの意見を表明しており、例外の原因に共感するコメントや反応はありませんでした。 他の議論を混乱させる以外に、同じことを繰り返すことで何が達成されるのかわかりません。 そしてそれがあなたの目標であるなら、それはただクールではありません。

@josharian 、簡単に議論を要約しようと思います。 私はミックスに提案があるのでバイアスがかかり、スレッド全体を読み直すつもりがないので不完全です。

私たちが対処しようとしている問題は、Goエラー処理によって引き起こされる視覚的な混乱です。 これが良い例です（ソース）：

func (ds *GitDataSource) Fetch(from, to string) ([]string, error) {
    if err := createFolderIfNotExist(to); err != nil {
        return nil, err
    }
    if err := clearFolder(to); err != nil {
        return nil, err
    }
    if err := cloneRepo(to, from); err != nil {
        return nil, err
    }
    dirs, err := getContentFolders(to)
    if err != nil {
        return nil, err
    }
    return dirs, nil
}

このスレッドの何人かのコメント投稿者は、これを修正する必要はないと考えています。 エラーの処理はエラー以外のケースの処理と同じくらい重要であるため、エラー処理が煩わしいことを喜んでいます。 彼らにとって、ここでの提案はどれも価値がありません。

このようなコードを単純化しようとする提案は、いくつかのグループに分けられます。

例外処理の形式を提案する人もいます。 Goが最初に例外処理を選択し、選択しないことを選択した可能性があることを考えると、これらは受け入れられそうにないようです。

ここでの提案の多くは、関数からの復帰（元の提案）やパニックなどのデフォルトのアクションを選択し、そのアクションを簡単に表現できるようにするための構文を提案します。 私の意見では、これらの提案はすべて失敗します。なぜなら、それらは他の人を犠牲にして1つの行動に特権を与えるからです。 私は定期的に返品、 t.Fatalとlog.Fatalを使用してエラーを処理しますが、すべて同じ日に行われることもあります。

他の提案では、元のエラーを補強またはラップする方法が提供されていないか、そうでない場合よりもラップが大幅に困難になっています。 エラーにコンテキストを追加する唯一の方法はラッピングであるため、これらも不十分です。スキップしやすくすると、現在よりも頻度が低くなります。

残りの提案のほとんどは、可能なアクションやラップする機能を制限することなく物事を単純化するために、砂糖と時には少しの魔法を追加します。 私と@bcmillsの提案は、最小限の砂糖とゼロの魔法を追加して、読みやすさをわずかに向上させ、厄介な種類のバグを防ぎます。

他のいくつかの提案では、関数の最初または最後のエラー処理セクションなど、ある種の制約された非ローカル制御フローが追加されています。

最後になりましたが、 @ mpvlは、は、読みやすさだけでなく正確さを向上させるために、Goエラー処理へのより根本的な変更を既存のメカニズムで処理できると思います。

アイデアがここに表示されていない人にはお詫びします。

砂糖と魔法の違いについて誰かに聞かれそうな気がします。 （私はそれを自分で尋ねています。）

シュガーは、言語のルールを根本的に変更することなくコードを短縮する少しの構文です。 短い代入演算子:=は砂糖です。 Cの三項演算子?:です。

マジックは、変数を宣言せずにスコープに導入したり、非ローカル制御転送を実行したりするなど、言語に対するより暴力的な混乱です。

線は間違いなくぼやけています。

それをしてくれてありがとう、@ jba。 非常に役立ちます。 ハイライトを引き出すために、これまでに特定された問題は次のとおりです。

Goエラー処理によって引き起こされる視覚的な混乱

と

パニックが発生すると、エラー処理が非常に難しくなる可能性があります

@jbaと私が見逃した他の根本的に異なる問題（解決策ではない）がある

@josharianスコーピングの問題（https://github.com/golang/go/issues/21161#issuecomment-319277657）を「視覚的な混乱」の問題の変形と見なしますか、それとも別の問題と見なしますか？

@bcmillsは、美学/人間工学（またはせいぜいコードのバルクを含む正確性の問題）とは対照的に、微妙な正確性の問題に関するものであるため、私には明確に思えます。 ありがとう！ コメントを編集して、その1行の概要を追加しますか？

砂糖と魔法の違いについて誰かに聞かれそうな気がします。 （私はそれを自分で尋ねています。）

私はこの魔法の定義を使用します。ソースコードを少し見て、次のアルゴリズムの変形によって何が行われるかを理解できるかどうかを確認します。

1. 行または関数に存在するすべての識別子、キーワード、および文法構造を検索します。
2. 文法の構成とキーワードについては、公用語のドキュメントを参照してください。
3. 識別子の場合、言語で定義されているように、コードが現在配置されているスコープを使用して、表示しているコードの情報を使用して識別子を見つけるための明確なメカニズムが必要です。このスコープから、識別子の定義を取得できます。実行時に正確である。

このアルゴリズムが_確実に_コードが何をしようとしているのかを正しく理解するのであれば、それは魔法ではありません。 そうでない場合は、ある程度の魔法が含まれています。 ドキュメントの参照と識別子の定義を他の識別子の定義までたどろうとするときに、どれだけ再帰的に適用する必要があるかは、問題の構成/コードの_複雑さ_には影響しますが、_魔法には影響しません。

魔法の例は次のとおりです。名前空間なしでインポートしたために元の場所に戻る明確なパスがない識別子（特に複数ある場合は、Goでドットをインポートします）。 コードが関数参照を非ローカルで完全に再定義できる動的言語や、存在しない識別子に対して言語が行うことを再定義できる動的言語など、言語が非ローカルで解決する対象を非ローカルで定義する必要がある場合があります。 実行時にデータベースからロードされたスキーマによって構築されたオブジェクト。したがって、コード時に、オブジェクトがそこにあることを多かれ少なかれ盲目的に望んでいます。

これの良いところは、ほとんどすべての主観性を問題から取り除くことです。

目前のトピックに戻ると、すでにたくさんの提案がなされているようで、他の誰かが別の提案でこれを解決する可能性があり、誰もが「はい！それだけです！」 ゼロに近づく。

おそらく、ここで行われた提案のさまざまな側面を分類し、優先順位を理解する方向に会話を進める必要があるように思われます。 特に、ここの人々が漠然と適用している矛盾した要件を明らかにすることを視野に入れて、これを見たいと思います。

たとえば、制御フローに追加のジャンプが追加されているという苦情がいくつかあります。 しかし、私自身、非常に独創的な提案の用語では、 || &PathError{"chdir", dir, err}が一般的である場合、関数内に8回追加する必要がないことを大切にしています。 （Goは他の言語ほど繰り返しコードにアレルギーがないことは知っていますが、それでも、繰り返しコードは発散バグのリスクが非常に高くなります。）しかし、定義上、このようなエラー処理を除外するメカニズムがある場合は、コードは、ジャンプなしで上から下、左から右に流れることはできません。 一般的にどちらがより重要であると考えられていますか？ 人々が暗黙のうちにコードに課している要件を注意深く調べると、他の相互に矛盾する要件が明らかになると思います。

しかし、一般的に、このすべての分析の後でコミュニティが要件に同意できれば、正しいソリューションは明らかに要件から外れる可能性があります。少なくとも、正しいソリューションセットは明らかに制約されているため、問題は扱いやすくなります。

（これは提案であるため、現在の動作は一般に新しい提案と同じ分析を行う必要があることも指摘しておきます。目標は完全ではなく大幅な改善です。2つまたは3つの重要な改善がないため拒否します。完璧は麻痺への道です。すべての提案はとにかく下位互換性があるので、現在のアプローチがとにかくすでに最善である場合（私見、すべてのエラーが合法的に異なる方法で処理される場合、これは私の経験ではまれですが発生します） 、現在のアプローチは引き続き利用できます。）

関数でerr！= nilを2回書いたときからこれについて考えていましたが、かなり単純な解決策は、三項の最初の部分のように見える条件付き戻りを許可することであると思います。条件が失敗すると、戻りません。

これが解析/コンパイルの観点からどれほどうまく機能するかはわかりませんが、「？」がどこにあるかをifステートメントとして解釈するのは簡単なはずです。 見えないところは互換性を崩さずに見えるので、オプションで捨ててみようと思いました。

さらに、これにはエラー処理以外の用途もあります。

したがって、次のようなことを行うことができます。

func example1() error {
    err := doSomething()
    return err != nil ? err
    //more code
}

func example2() (*Mything, error) {
    err := doSomething()
    return err != nil ? nil, err
    //more code
}

handleErrがerrを返したと仮定して、クリーンアップコードがある場合は、次のようなこともできます。

func example3() error {
    err := doSomething()
    return err !=nil ? handleErr(err)
    //more code
}

func example4() (*Mything, error) {
    err := doSomething()
    return err != nil ? nil, handleErr(err)
    //more code
}

おそらく、必要に応じて、これを1つのライナーに減らすことができるということにもなります。

func example5() error {
    return err := doSomething(); err !=nil ? handleErr(err)
    //more code
}

func example6() (*Mything, error) {
    return err := doSomething(); err !=nil ? nil, handleErr(err)
    //more code
}

@jbaからの以前のフェッチの例は、

func (ds *GitDataSource) Fetch(from, to string) ([]string, error) {

    return err := createFolderIfNotExist(to); err != nil ? nil, err
    return err := clearFolder(to); err != nil ? nil, err
    return err := cloneRepo(to, from); err != nil ? nil, err
    dirs, err := getContentFolders(to)

    return dirs, err
}

この提案への反応に興味があるでしょう。おそらくボイラープレートを節約する上で大きな勝利ではありませんが、非常に明確であり、うまくいけば、小さな下位互換性のある変更のみが必要です（おそらくその前にいくつかの非常に不正確な仮定）。

あなたはおそらくこれを別のリターンで分離することができますか？ （すべてのツールを考えて）returnとの互換性を心配する必要がないという点で、明確さを増し、生活を簡素化する可能性のあるキーワード。これらは、if / returnステートメントとして内部的に書き直され、次のようになります。

func (ds *GitDataSource) Fetch(from, to string) ([]string, error) {

    return? err := createFolderIfNotExist(to); err != nil ? nil, err
    return? err := clearFolder(to); err != nil ? nil, err
    return? err := cloneRepo(to, from); err != nil ? nil, err
    dirs, err := getContentFolders(to)

    return dirs, err
}

違いはあまりないようです

return err != nil ? err

と

 if err != nil { return err }

また、 panicやlog.Fatal呼び出すなど、返品以外のことをしたい場合もあります。

私は先週提案を提出して以来、これを回転させてきました、そして私は@thejerfに同意するという結論に達しました：私たちは実際に一歩

最も一般的に述べられている要件は、1日の終わりに、Goが4つのエラー処理ケースを処理できる必要があるということです。

1. エラーを無視する
2. 変更せずにエラーを返す
3. コンテキストを追加してエラーを返す
4. パニック（またはプログラムの強制終了）

提案は、次の3つのカテゴリのいずれかに分類されるようです。

1. try-catch-finallyスタイルのエラー処理に戻します。
2. 上記の4つのケースすべてを処理するために、新しい構文/ビルトインを追加します
3. それを主張することはいくつかのケースを十分に処理し、他のケースを助けるために構文/ビルトインを提案します。

与えられた提案に対する批判は、コードの可読性、非自明なジャンプ、スコープへの変数の暗黙的な追加、および簡潔さに関する懸念に分かれているようです。 個人的には、提案に対する批判には個人的な意見がたくさんあったと思います。 それが悪いことだと言っているわけではありませんが、提案を評価するための客観的な基準は実際にはないように思えます。

私はおそらくその基準のリストを作成しようとする人ではありませんが、誰かがそれをまとめるのであれば非常に役立つと思います。 私は、1。見たもの、2。何が悪いのか、3。

@jbaには、より多くのコンテキストのために、上記の別の素晴らしい要約コメントがあります。 彼は私がここで言ったことの多くを別の言葉で言います。

@ianlancetaylor 、または私よりもプロジェクトに深く関わっている人は、満たす必要のある「正式な」（すべて1つのコメントで、整理され、ある程度包括的ですが、拘束力はありません）一連の基準を追加することに

包括的な正式な基準のセットを書くことはできないと思います。 私ができる最善のことは、そうすることに大きな利益がある場合にのみ無視されるべき重要な事柄の不完全なリストです。

• 1）エラーを無視するための優れたサポート。 2）変更せずにエラーを返す。 3）追加のコンテキストでエラーをラップします。
• エラー処理コードは明確である必要がありますが、機能を支配するべきではありません。 エラー処理以外のコードは読みやすいはずです。
• 既存のGo1コードは引き続き機能する必要があります。または、少なくとも、Go1を完全な信頼性で新しいアプローチに機械的に変換できる必要があります。
• 新しいアプローチは、プログラマーがエラーを正しく処理することを奨励するはずです。 どんな状況でも正しいことをするのは理想的には簡単なはずです。
• 新しいアプローチは、明確なままで、現在のアプローチよりも短く、および/または繰り返しを少なくする必要があります。
• この言語は今日でも機能し、すべての変更にはコストがかかります。 変更のメリットは、明らかにコストに見合うものでなければなりません。 それは単なる洗浄ではなく、明らかに優れているはずです。

私はここでいつかメモを収集したいと思っていますが、この議論のもう1つの大きな障害である、例の些細なことであるIMHOについて説明したいと思います。

私はこれを私の実際のプロジェクトから抽出し、外部リリースのためにスクラブしました。 （stdlibは、特にロギングの懸念が欠落しているため、最良のソースではないと思います。）

func NewClient(...) (*Client, error) {
    listener, err := net.Listen("tcp4", listenAddr)
    if err != nil {
        return nil, err
    }
    defer func() {
        if err != nil {
            listener.Close()
        }
    }()

    conn, err := ConnectionManager{}.connect(server, tlsConfig)
    if err != nil {
        return nil, err
    }
    defer func() {
        if err != nil {
            conn.Close()
        }
    }()

    if forwardPort == 0 {
        env, err := environment.GetRuntimeEnvironment()
        if err != nil {
            log.Printf("not forwarding because: %v", err)
        } else {
            forwardPort, err = env.PortToForward()
            if err != nil {
                log.Printf("env couldn't provide forward port: %v", err)
            }
        }
    }
    var forwardOut *forwarding.ForwardOut
    if forwardPort != 0 {
        u, _ := url.Parse(fmt.Sprintf("http://127.0.0.1:%d", forwardPort))
        forwardOut = forwarding.NewOut(u)
    }

    client := &Client{...}

    toServer := communicationProtocol.Wrap(conn)
    err = toServer.Send(&client.serverConfig)
    if err != nil {
        return nil, err
    }

    err = toServer.Send(&stprotocol.ClientProtocolAck{ClientVersion: Version})
    if err != nil {
        return nil, err
    }

    session, err := communicationProtocol.FinalProtocol(conn)
    if err != nil {
        return nil, err
    }
    client.session = session

    return client, nil
}

（コードをあまり流用しないようにしましょう。もちろん、あなたを止めることはできませんが、これは私の本当のコードではなく、少し混乱していることを覚えておいてください。そして、あなたがあなた自身のサンプルコードを投稿するのを止めることはできません。）

観察：

1. これは完璧なコードではありません。 非常に簡単で、まさに私たちが問題を抱えている種類のコードであるため、私は裸のエラーをたくさん返します。 提案は、簡潔さと、このコードの修正をどれだけ簡単に実証できるかによってスコアリングする必要があります。
2. if forwardPort == 0句は_deliberately_でエラーが発生し続けます。はい、これは実際の動作であり、この例で追加したものではありません。
3. このコードは、有効な接続されたクライアントを返すか、エラーを返し、リソースリークがないため、.Close（）周辺の処理（関数がエラーになった場合のみ）は意図的なものです。 実際のGoで非常に一般的であるように、Closeからのエラーも消えることに注意してください。
4. ポート番号は他の場所で制約されているため、url.Parseは失敗することはありません（調査による）。

これが考えられるすべてのエラー動作を示しているとは言えませんが、かなりの範囲をカバーしています。 （私はGo on HNなどを擁護することがよくあります。コードの作成が完了するまでに、ネットワークサーバーでは、あらゆる種類のエラー動作が発生することがよくあります。自分の本番コードを1/3から調べます。エラーの完全に1/2にすることは、単に返される以外のことをしました。）

私はまた、このコードに適用された自分の（更新された）提案を（再）投稿します（誰かがそれ以前にもっと良いものを持っていると私に納得させない限り）が、会話を独占しないために私は待つつもりです少なくとも週末は。 （これは、ソースの巨大なチャンクであるため、見た目よりも少ないテキストですが、それでも....）

tryここで、 tryは、！= nil returnがコードを59のうち6行（約10％）削減する場合のショートカットです。

func NewClient(...) (*Client, error) {
    listener, err := net.Listen("tcp4", listenAddr)
    try err

    defer func() {
        if err != nil {
            listener.Close()
        }
    }()

    conn, err := ConnectionManager{}.connect(server, tlsConfig)
    try err

    defer func() {
        if err != nil {
            conn.Close()
        }
    }()

    if forwardPort == 0 {
        env, err := environment.GetRuntimeEnvironment()
        if err != nil {
            log.Printf("not forwarding because: %v", err)
        } else {
            forwardPort, err = env.PortToForward()
            if err != nil {
                log.Printf("env couldn't provide forward port: %v", err)
            }
        }
    }
    var forwardOut *forwarding.ForwardOut
    if forwardPort != 0 {
        u, _ := url.Parse(fmt.Sprintf("http://127.0.0.1:%d", forwardPort))
        forwardOut = forwarding.NewOut(u)
    }

    client := &Client{...}

    toServer := communicationProtocol.Wrap(conn)
    err = toServer.Send(&client.serverConfig)
    try err

    err = toServer.Send(&stprotocol.ClientProtocolAck{ClientVersion: Version})
    try err

    session, err := communicationProtocol.FinalProtocol(conn)
    try err

    client.session = session

    return client, nil
}

特に、いくつかの場所でtry x()を書きたかったのですが、defersが正しく機能するようにエラーを設定する必要があったため、書き込めません

もう1つ。 tryが割り当て行で発生する可能性がある場合、47行になります。

func NewClient(...) (*Client, error) {
    try listener, err := net.Listen("tcp4", listenAddr)

    defer func() {
        if err != nil {
            listener.Close()
        }
    }()

    try conn, err := ConnectionManager{}.connect(server, tlsConfig)

    defer func() {
        if err != nil {
            conn.Close()
        }
    }()

    if forwardPort == 0 {
        env, err := environment.GetRuntimeEnvironment()
        if err != nil {
            log.Printf("not forwarding because: %v", err)
        } else {
            forwardPort, err = env.PortToForward()
            if err != nil {
                log.Printf("env couldn't provide forward port: %v", err)
            }
        }
    }
    var forwardOut *forwarding.ForwardOut
    if forwardPort != 0 {
        u, _ := url.Parse(fmt.Sprintf("http://127.0.0.1:%d", forwardPort))
        forwardOut = forwarding.NewOut(u)
    }

    client := &Client{...}

    toServer := communicationProtocol.Wrap(conn)
    try err = toServer.Send(&client.serverConfig)

    try err = toServer.Send(&stprotocol.ClientProtocolAck{ClientVersion: Version})

    try session, err := communicationProtocol.FinalProtocol(conn)

    client.session = session

    return client, nil
}

import "github.com/pkg/errors"

func Func3() (T1, T2, error) {...}

type PathError {
    err Error
    x   T3
    y   T4
}

type MiscError {
    x   T5
    y   T6
    err Error
}


func Foo() (T1, T2, error) {
    // Old school
    a, b, err := Func(3)
    if err != nil {
        return nil
    }

    // Simplest form.
    // If last unhandled arg's type is same 
    // as last param of func,
    // then use anon variable,
    // check and return
    a, b := Func3()
    /*    
    a, b, err := Func3()
    if err != nil {
         return T1{}, T2{}, err
    }
    */

    // Simple wrapper
    // If wrappers 1st param TypeOf Error - then pass last and only unhandled arg from Func3() there
    a, b, errors.WithStack() := Func3() 
    /*
    a, b, err := Func3()
    if err != nil {
        return T1{}, T2{}, errors.WithStack(err)
    }
    */

    // Bit more complex wrapper
    a, b, errors.WithMessage("unable to get a and b") := Func3()
    /*
    a, b, err := Func3()
    if err != nil {
        return T1{}, T2{}, errors.WithMessage(err, "unable to get a and b")
    }
    */

    // More complex wrapper
    // If wrappers 1nd param TypeOf is not Error - then pass last and only unhandled arg from Func3() as last
    a, b, fmt.Errorf("at %v Func3() return error %v", time.Now()) := Func3()
    /*
    a, b, err := Func3()
    if err != nil {
        return T1{}, T2{}, fmt.Errorf("at %v Func3() return error %v", time.Now(), err)
    }
    */

    // Wrapping with error types
    a, b, &PathError{x,y} := Func3()
    /*
    a, b, err := Func3()
    if err != nil {
        return T1{}, T2{}, &PathError{err, x, y}
    }
    */
    a, b, &MiscError{x,y} := Func3()
    /*
    a, b, err := Func3()
    if err != nil {
        return T1{}, T2{}, &MiscError{x, y, err}
    }
    */

    return a, b, nil
}

やや魔法（-1までお気軽に）ですが、機械的な翻訳をサポートしています

これは私の提案が（いくらか更新された）どのようになるかです：

func NewClient(...) (*Client, error) {
    defer annotateError("client couldn't be created")

    listener := pop net.Listen("tcp4", listenAddr)
    defer closeOnErr(listener)
    conn := pop ConnectionManager{}.connect(server, tlsConfig)
    defer closeOnErr(conn)

    if forwardPort == 0 {
        env, err := environment.GetRuntimeEnvironment()
        if err != nil {
            log.Printf("not forwarding because: %v", err)
        } else {
            forwardPort, err = env.PortToForward()
            if err != nil {
                log.Printf("env couldn't provide forward port: %v", err)
            }
        }
    }
    var forwardOut *forwarding.ForwardOut
    if forwardPort != 0 {
         forwardOut = forwarding.NewOut(pop url.Parse(fmt.Sprintf("http://127.0.0.1:%d", forwardPort)))
    }

    client := &Client{listener: listener, conn: conn, forward: forwardOut}

    toServer := communicationProtocol.Wrap(conn)
    pop toServer.Send(&client.serverConfig)
    pop toServer.Send(&stprotocol.ClientProtocolAck{ClientVersion: Version})
    session := pop communicationProtocol.FinalProtocol(conn)
    client.session = session

    return client, nil
}

func closeOnErr(c io.Closer) {
    if err := erroring(); err != nil {
        closeErr := c.Close()
        if err != nil {
            seterr(multierror.Append(err, closeErr))
        }
    }
}

func annotateError(annotation string) {
    if err := erroring(); err != nil {
        log.Printf("%s: %v", annotation, err)
        seterr(errwrap.Wrapf(annotation +": {{err}}", err))
    }
}

定義：

popは、右端の値がエラーである関数式に対して有効です。 これは、「エラーがnilでない場合は、結果内の他のすべての値とそのエラーの値がゼロの関数から戻り、それ以外の場合はエラーのない値のセットを生成する」と定義されています。 popは、 erroring()との特権的なやり取りはありません。 エラーの通常の戻り値は、引き続きerroring()ます。 これは、他の戻り値に対してゼロ以外の値を返すことができ、それでも遅延エラー処理を使用できることを意味します。 比喩は、戻り値の「リスト」から右端の要素をポップしています。

erroring()は、スタックを上って実行中の遅延関数に移動し、次に前のスタック要素（遅延が実行されている関数、この場合はNewClient）に移動して、現在返されたエラーの値にアクセスすることとして定義されます。進行中。 関数にそのようなパラメーターがない場合は、パニックになるか、nilを返します（どちらか意味のある方）。 このエラー値はpopからのものである必要はありません。 ターゲット関数からエラーを返すものです。

seterr(error)使用すると、返されるエラー値を変更できます。 これは、将来のerroring()呼び出しで見られるエラーになります。これにより、ここに示すように、現在実行できるのと同じ遅延ベースのチェーンが可能になります。

ここでは、hashicorpラッピングとマルチエラーを使用しています。 必要に応じて、独自の巧妙なパッケージを挿入します。

追加の関数を定義しても、合計は短くなります。 追加の用途で2つの関数を償却することを期待しているので、それらは部分的にしかカウントされません。

構文をさらに詰め込むのではなく、forwardPortの処理をそのままにしておくことに注意してください。 例外的なケースとして、これがより冗長であっても問題ありません。

この提案IMHOの最も興味深い点は、従来の例外を除いてこれを書き込もうとしていることを想像した場合にのみ見ることができます。 最終的にはかなり深くネストされ、発生する可能性のあるエラーの_コレクション_を処理することは、例外処理では非常に面倒です。 （実際のGoコードと同様に、.Closeエラーは無視される傾向があり、例外ハンドラー自体で発生するエラーは、例外ベースのコードでは無視される傾向があります。）

これにより、 deferなどの既存のGoパターンが拡張され、値としてのエラーを使用して、現在のGoまたは例外のいずれかで表現するのが困難な場合に、根本的な手術を必要としないエラー処理パターンを簡単に修正できます。ランタイムに（私は思いませんが）、また、実際にはGo2.0を_必要としません_。

欠点には、 erroring 、 pop 、およびseterrをキーワードとして要求すること、これらの機能にdeferオーバーヘッドが発生することが含まれます。これは、因数分解されたエラー処理が一部を飛び回るという事実です。処理機能に、そしてそれが正しい処理を「強制する」ために何もしないこと。 最後が可能かどうかはわかりませんが、下位互換性があるという（正しい）要件により、常に現在のことを実行できます。

ここで非常に興味深い議論。

魔法のように現れる変数が導入されないように、エラー変数を左側に残しておきたいと思います。 元の提案と同様に、同じ行でエラーを処理したいと思います。 ||演算子は「ブール値が大きすぎる」ように見え、どういうわけか「リターン」を隠すため、使用しません。

したがって、拡張キーワード「return？」を使用して読みやすくします。 C＃では、ショートカットを作成するためにいくつかの場所で疑問符が使用されます。 例： 書く代わりに：

if(foo != null)
{ foo.Bar(); }

あなたはただ書くことができます：
foo?.Bar();

したがって、Go 2の場合、このソリューションを提案したいと思います。

func foobar() error {
    return fmt.Errorf("Some error happened")
}

// Implicitly return err (there must be exactly one error variable on the left side)
err := foobar() return?
// Explicitly return err
err := foobar() return? err
// Return extended error info
err := foobar() return? &PathError{"chdir", dir, err}
// Return tuple
err := foobar() return? -1, err
// Return result of function (e. g. for logging the error)
err := foobar() return? handleError(err)
// This doesn't compile as you ignore the error intentionally
foobar() return?

ちょっとした考え：

foo、err：= myFunc（）
err！= nil？ return wrap（err）

または

err！= nil？ return wrap（err）

その周りに中かっこを付けても構わないと思っているなら、何も変更する必要はありません！

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

必要なカスタム処理を_すべて_行うことができ（またはまったく行わない）、通常の場合から2行のコードを節約し、100％下位互換性があり（言語に変更がないため）、よりコンパクトで、簡単。 それはイアンのドライビングポイントの多くにgofmtツールかもしれませんか？

私はcarlmjohnsonの提案を読む前にこれを書きました。これは似ています...

エラーの前に#だけ。

ただし、実際のアプリケーションでは、エラーをログに記録できるように通常のif err != nil { ... }する必要があります。これにより、 afterというアノテーションを使用してリターンミドルウェアを追加できない限り、最小限のエラー処理は役に立ちません。 、関数が戻った後に実行されます...（ defer同様ですが、引数を使用します）。

@after(func (data string, err error) {
  if err != nil {
    log.Error("error", data, " - ", err)
  }
})
func alo() (string, error) {
  // this is the equivalent of
  // data, err := db.Find()
  // if err != nil { 
  //   return "", err 
  // }
  str, #err := db.Find()

  // ...

  #err = db.Create()

  // ...

  return str, nil
}

func alo2() ([]byte, []byte, error, error) {
  // this is the equivalent of
  // data, data2, err, errNotFound := db.Find()
  // if err != nil { 
  //   return nil, nil, err, nil
  // } else if errNotFound != nil {
  //   return nil, nil, nil, errNotFound
  // }
  data, data2, #err, #errNotFound := db.Find()

  // ...

  return data, data2, nil, nil
}

よりクリーン：

func alo() (string, error) {
  str, err := db.Find()
  if err != nil {
    log.Error("error on find in database", err)
    return "", err
  }

  // ...

  if err := db.Create(); err != nil {
    log.Error("error on create", err)
    return "", err
  }

  // ...

  return str, nil
}

func alo2() ([]byte, []byte, error, error) {
  data, data2, err, errNotFound := db.Find()
  if err != nil { 
    return nil, nil, err, nil
  } else if errNotFound != nil {
    return nil, nil, nil, errNotFound
  }

  // ...

  return data, data2, nil, nil
}

以下のようなスウィフトについてどのようにguard文で、代わりに除く外guard...elseそれのguard...return ：

file, err := os.Open("fails.txt")
guard err return &FooError{"Couldn't foo fails.txt", err}

guard os.Remove("fails.txt") return &FooError{"Couldn't remove fails.txt", err}

私はgoエラー処理の明示性が好きです。 唯一の問題、imhoは、どれだけのスペースが必要かということです。 私は2つの微調整を提案します：

1. nilはfalseと同等であり、 nilからtrue場合、ブール型のコンテキストでnil-ableアイテムを使用できるようにします。
2. &&や||単一行の条件付きステートメント演算子をサポートします

そう

file, err := os.Open("fails.txt")
if err != nil {
    return &FooError{"Couldn't foo fails.txt", err}
}

になることができる

file, err := os.Open("fails.txt")
if err {
    return &FooError{"Couldn't foo fails.txt", err}
}

またはさらに短い

file, err := os.Open("fails.txt")
err && return &FooError{"Couldn't foo fails.txt", err}

そして、私たちはすることができます

i,ok := v.(int)
ok || return fmt.Errorf("not a number")

多分

i,ok := v.(int)
ok && s *= i

&&と||をオーバーロードするとあいまいさが大きくなりすぎる場合は、他の文字（2つ以下）を選択できます。たとえば、 ?と#または??と## 、または??と!!など。 重要なのは、最小限の「ノイズの多い」文字（括弧、中括弧などは不要）を含む1行の条件文をサポートすることです。 演算子&&と||は、この使用法が他の言語で前例があるため、適切です。

これは、複雑な1行の条件式をサポートするための提案ではなく、1行の条件ステートメントのみをサポートするものです。

また、これは他のいくつかの言語の「真実」の全範囲をサポートするための提案ではありません。 これらの条件は、 nil / non-nil、またはブール値

これらの条件演算子の場合、式をサポートせずに単一の変数に制限することが適切な場合もあります。 より複雑なもの、またはelse句を使用するものは、標準のif ...構造で処理されます。

@mattnが前に言ったように、なぜホイールを発明して既知のtry..catchフォームを使用しないのですか？ ）。

try {
    a := foo() // func foo(string, error)
    b := bar() // func bar(string, error)
} catch (err) {
    // handle error
}

あなたが本当にこれを必要とする場合は、必ず古い形式を使用する可能性があるため、catchedエラー源を区別する理由はないように思えるif err != nilせずにtry..catch 。

また、それについてはよくわかりませんが、エラーが処理されない場合にエラーを「スロー」する機能を追加する可能性がありますか？

func foo() (string, error) {
    f := bar() // similar to if err != nil { return "", err }
}

func baz() string {
    // Compilation error.
    // bar's error must be handled because baz() does not return error.
    return bar()
}

読みやすさの観点から、 @ gobwasは制御フローを完全に理解することが非常に重要です。 あなたの例を見ると、どの行がキャッチブロックにジャンプする可能性があるかはわかりません。 これは、隠されたgotoステートメントのようなものです。 現代語がそれについて明示的にしようとし、エラーがスローされたために制御フローが分岐する可能性のある場所を明示的にマークするようにプログラマーに要求するのも不思議ではありません。 returnまたはgotoとほとんど同じですが、構文がはるかに優れています。

@crekerはい、私はあなたに完全に同意します。 上記の例でフロー制御を考えていましたが、簡単な形でこれを行う方法を理解していませんでした。

多分次のようなものです：

try {
    a ::= foo() // func foo(string, error)
    b ::= bar() // func bar(string, error)
} catch (err) {
    // handle error
}

またはtry a := foo() ..のような前の他の提案？

@gobwas

catchブロックに到達したとき、tryブロックのどの関数がエラーの原因であるかをどのように知ることができますか？

@urandomそれを知る必要がある場合は、おそらくif err != nilなしでtry..catch if err != nilを実行したいと思うでしょう。

@ robert-wallis：スレッドの前半でSwiftのガードステートメントについて説明

@pdk

nil可能なアイテムをブールコンテキストで使用できるようにします。nilはfalseに相当し、nil以外はtrueに相当します。

これにより、フラグパッケージを使用して多くのバグが発生し、人々はif myflag { ... }を書き込みますが、 if *myflag { ... }を書き込むことを意味し、コンパイラによって検出されません。

try / catchは、複数のことを連続して試行する場合のif / elseよりも短いだけです。これは、制御フローの問題などのために、多かれ少なかれ誰もが同意するものです。

FWIW、Swiftのtry / catchは、少なくとも、どのステートメントがスローされるかわからないという視覚的な問題を解決します。

do {
    let dragon = try summonDefaultDragon() 
    try dragon.breathFire()
} catch DragonError.dragonIsMissing {
    // ...
} catch DragonError.halatosis {
    // ...
}

@ robert-wallis、例があります：

file, err := os.Open("fails.txt")
guard err return &FooError{"Couldn't foo fails.txt", err}

guard os.Remove("fails.txt") return &FooError{"Couldn't remove fails.txt", err}

guard初めて使用したときは、 if err != nil { return &FooError{"Couldn't foo fails.txt", err}}に非常によく似ているので、それが大きな成果かどうかはわかりません。

2回目の使用では、 errがどこから来たのかすぐにはわかりません。 os.Openから返されたもののように見えますが、これはあなたの意図ではなかったと思いますか？ これはもっと正確でしょうか？

guard err = os.Remove("fails.txt") return &FooError{"Couldn't remove fails.txt", err}

その場合、それは次のようになります...

if err = os.Remove("fails.txt"); err != nil { return &FooError{"Couldn't remove fails.txt", err}}

しかし、それでも視覚的な混乱は少なくなります。 if err = 、 ; err != nil { -たとえそれがワンライナーであっても、そのような単純なことにはまだ多くのことが起こっています

散らかっていないことに同意しました。 しかし、言語に追加することを保証するために、かなり少ないですか？ そこに同意するかどうかはわかりません。

Java / C＃/ ...のtry-catchブロックの可読性は、エラー処理によって中断されることなく「ハッピーパス」シーケンスをたどることができるため、非常に優れていると思います。 欠点は、基本的に隠されたgotoメカニズムがあることです。

Goでは、エラーハンドラの後に空の行を挿入して、「ハッピーパス」ロジックの継続をより明確にします。 したがって、golang.orgからのこのサンプルから（9行）

record := new(Record)
err := datastore.Get(c, key, record) 
if err != nil {
    return &appError{err, "Record not found", 404}
}
err := viewTemplate.Execute(w, record)
if err != nil {
    return &appError{err, "Can't display record", 500}
}

私はよくそれをします（11行）

record := new(Record)

err := datastore.Get(c, key, record) 
if err != nil {
    return &appError{err, "Record not found", 404}
}

err := viewTemplate.Execute(w, record)
if err != nil {
    return &appError{err, "Can't display record", 500}
}

さて、提案に戻りましょう。私はすでにこのようなものを投稿しているので、いいでしょう（3行）

record := new(Record)
err := datastore.Get(c, key, record) return? &appError{err, "Record not found", 404}
err := viewTemplate.Execute(w, record) return? &appError{err, "Can't display record", 500}

今、私は幸せな道をはっきりと見ています。 私の目は、右側にエラー処理用のコードがあることをまだ認識していますが、本当に必要な場合にのみ「目で解析」する必要があります。

側のすべての人への質問：このコードはコンパイルする必要がありますか？

func foobar() error {
    return fmt.Errorf("Some error")
}
func main() {
    foobar()
}

IMHOユーザーは、次のエラーを意図的に無視していると言わざるを得ないはずです。

func main() {
    _ := foobar()
}

@ianlancetaylorの元の投稿のポイント3に関連するミニエクスペリエンスレポートを追加し、追加のコンテキスト情報とともにエラーを返します。

Go用のflacライブラリを開発するとき、 @ davecheney pkg / errorsパッケージ（https://github.com/mewkiz/flac/issues/22）を使用してエラーにコンテキスト情報を追加したいと思いました。 具体的には、エラーをスタックトレース情報で注釈するerrors.WithStackを使用して

エラーには注釈が付けられているため、errors.WithStackの場合、この追加情報を格納するための新しい基になるタイプを作成する必要があります。タイプはerrors.withStackです。

type withStack struct {
    error
    *stack
}

ここで、元のエラーを取得するための規則は、 errors.Causeを使用することio.EOFと比較できます。

ライブラリのユーザーは、 https：//github.com/mewkiz/flac/blob/0884ed715ef801ce2ce0c262d1e674fdda6c3d94/cmd/flac2wav/flac2wav.go#L78に沿って、 errors.Causeを使用して元のエラーを確認するために何かを書くことができます。価値：

frame, err := stream.ParseNext()
if err != nil {
    if errors.Cause(err) == io.EOF {
        break
    }
    return errors.WithStack(err)
}

これはほとんどすべての場合にうまく機能します。

エラー処理をリファクタリングして、コンテキスト情報を追加するためにpkg / errorsを一貫して使用する場合、かなり深刻な問題が発生しました。 ゼロパディングを検証するために、読み取りバイトがゼロかどうかをチェックするだけのio.Readerをが失敗し始めたことです。

問題は、 zeros.Readによって返されるエラーの根本的なタイプが、io.EOFではなくerrors.withStackであるということでした。 したがって、その後、我々はとの組み合わせでそのリーダーを使用する際の問題を引き起こしたio.Copyのためにこれをチェックし、 io.EOF具体的には、および使用することを知らないerrors.Cause 「アンラップ」への注釈が付けエラーをコンテキスト情報。 標準ライブラリを更新できないため、解決策は注釈付きの情報なしでエラーを返すことでした（https://github.com/mewkiz/flac/commit/6805a34d854d57b12f72fd74304ac296fd0c07be）。

具体的な値を返すインターフェイスの注釈付き情報を失うことは損失ですが、一緒に暮らすことは可能です。

私たちの経験からの脱却は、私たちのテストケースがこれを捕らえたので、私たちが幸運だったということです。 zerosタイプはまだio.Readerインターフェースを実装しているため、コンパイラーはエラーを生成しません

しかし、それは実現しました。そのため、私たちは経験レポートを検討のために提供したいと考えています。 コンテキスト情報の追加をGo2のエラー処理に統合する方法を考えるとき、エラー比較（インターフェイスコントラクトで使用される）がシームレスに保持されるようにします。

親切に、
ロビン

@mewmew 、エラー処理の制御フローの側面についてこの問題を維持しましょう。 エラーのラップとアンラップの最適な方法については、制御フローとほぼ直交しているため、他の場所で説明する必要があります。

私はあなたのコードベースに精通しておらず、自動リファクタリングだと言っていたと思いますが、なぜEOFにコンテキスト情報を含める必要があったのですか？ 型システムではエラーとして扱われますが、EOFは実際のエラーではなく、実際にはシグナル値です。 特にio.Reader実装では、ほとんどの場合、これは期待値です。 io.EOFない場合にのみエラーをラップすることで、より良い修正はありませんか？

ええ、私は物事をそのままにしておくことを提案します。 Goのエラーシステムは、開発者がコールスタックにエラーをパントするのを思いとどまらせるために、このように意図的に設計されているという印象を受けました。 そのエラーは、発生した場所で解決され、できないときにパニックを使用する方が適切な場合を知ることを目的としています。

つまり、try-catch-throwは、とにかくpanic（）とrecover（）の動作と本質的に同じではありませんか？

ため息をつく、もし私たちが本当にこの道を下り始めようとしているのなら。 なぜ私たちはただのようなことをすることができないのですか

_, ? := foo()
x?, err? := bar()

またはおそらく何かのようなもの

_, err := foo(); return err?
x, err := bar(); return x? || err?
x, y, err := baz(); return (x? && y?) || err?

どこ ？ if var！= nil {returnvar}の省略形のエイリアスになります。

メソッドによって満たされる別の特別な組み込みインターフェースを定義することもできます

func ?() bool //looks funky but avoids breakage.

これを使用して、新しく改良された条件演算子のデフォルトの動作を基本的にオーバーライドできます。

@mortdeus

同意すると思います。
問題がハッピーパスを提示するための優れた方法を持つことである場合、IDEのプラグインはショートカットを使用してif err != nil { return [...] }すべてのインスタンスを折りたたむ/展開することができますか？

今はすべての部分が重要だと感じています。 err != nilは重要です。 return ...は重要です。
書くのは少し面倒ですが、書かなければなりません。 そして、それは本当に人々を遅くしますか？ 時間がかかるのは、エラーを書くのではなく、エラーと何を返すかを考えることです。

err変数の範囲を制限できる提案にもっと興味があります。

私の条件付きのアイデアは、この問題を解決するための最も良い方法だと思います。 この機能をGoに含めるのに十分な価値があるようにする他のいくつかのことを考えました。 私は別の提案で私の考えを書き留めるつもりです。

これがどのように機能するかわかりません：

x、y、err：= baz（）; return（ x? && y? ）|| err?

どこ ？ if var == nil {returnvar}の省略形のエイリアスになります。

x、y、err：= baz（）; return（ if x == nil{ return x} && if y== nil{ return y} ）|| if err == nil{ return err}

x、y、err：= baz（）; return（x？&& y？）|| え？

になります

x、y、err：= baz（）;
if（（x！= nil && y！= nil）|| err！= nil））{
x、y、errを返す
}

xを見たら？ && y？ || え？ 「xとyは有効ですか？エラーはどうですか？」と考える必要があります。

そうでない場合、return関数は実行されません。 このアイデアについて、新しい特別な組み込みインターフェースタイプでアイデアを少し進めた新しい提案を書きました。

Goバージョン2でデフォルトのエラー処理を追加することをお勧めします。

ユーザーがエラーを処理しない場合、コンパイラはnilでない場合はエラーを返すため、ユーザーが次のように記述します。

func Func() error {
    func1()
    func2()
    return nil
}

func func1() error {
    ...
}

func func2() error {
    ...
}

コンパイルして次のように変換します。

func Func() error {
    err := func1()
    if err != nil {
        return err
    }

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

    return nil
}

func func1() error {
    ...
}

func func2() error {
    ...
}

ユーザーがエラーを処理するか、_を使用して無視した場合、コンパイラは何もしません。

_ = func1()

また

err := func1()

複数の戻り値の場合、次のようになります。

func Func() (*YYY, error) {
    ch, x := func1()
    return yyy, nil
}

func func1() (chan int, *XXX, error) {
    ...
}

コンパイラは次のように変換されます。

func Func() (*YYY, error) {
    ch, x, err := func1()
    if err != nil {
        return nil, err
    }

    return yyy, nil
}

func func1() (chan int, *XXX, error) {
    ...
}

Func（）のシグネチャがエラーを返さないが、エラーを返す関数を呼び出す場合、コンパイラはエラーを報告します：「Func（）でエラーを処理してください」
その後、ユーザーはFunc（）でエラーをログに記録できます。

そして、ユーザーがいくつかの情報をエラーにラップしたい場合：

func Func() (*YYY, error) {
    ch, x := func1() ? Wrap(err, "xxxxx", ch, "abc", ...)
    return yyy, nil
}

また

func Func() (*YYY, error) {
    ch, x := func1() ? errors.New("another error")
    return yyy, nil
}

利点は、

1. プログラムはエラーが発生した時点で失敗するだけであり、ユーザーはエラーを暗黙的に無視することはできません。
2. コードの行を大幅に減らすことができます。

Goは複数の戻り値を持つ可能性があり、開発者が何が起こっているのかを明示的に認識しない限り、言語は戻り引数のデフォルト値に本質的に等しいものを割り当てるべきではないため、それほど簡単ではありません。

代入構文にエラー処理を入れても、「エラー処理は繰り返される」という問題の根本は解決しないと思います。

コードの多くの行の後にif (err != nil) { return nil } （または同様のもの）を使用すると（そうすることが理にかなっている場合）、DRY（自分自身を繰り返さないでください）プリンシパルに反します。 それが私たちがこれを嫌う理由だと思います。

try ... catchも問題があります。 エラーが発生したのと同じ関数でエラーを明示的に処理する必要はありません。 それが私たちがtry...catchを嫌う注目すべき理由だと思います。

これらは相互に排他的ではないと思います。 我々は一種の持つことができますtry...catchせずにthrows 。

私が個人的にtry...catchについて嫌いなもう一つのことは、 tryキーワードの恣意的な必要性です。 動作する文法に関する限り、スコープリミッターの後でcatch実行できない理由はありません。 （私がこれについて間違っているなら誰かがそれを呼びます）

これは私が提案するものです：

• 返されたエラーのプレースホルダーとして?を使用します。ここで、 _はそれを無視するために使用されます
• 代わりにcatch以下の私の例のように、 error? 、完全な後方互換性のために代わりに使用することができ

^これらが下位互換性があるという私の仮定が正しくない場合は、それを呼び出してください。

func example() {
    {
        // The following line will invoke the catch block
        data, ? := foopkg.buyIt()
        // The next two lines handle an error differently
        otherData, err := foopkg.useIt()
        if err != nil {
            // Here we eliminated deeper indentation
            otherData, ? = foopkg.breakIt()
        }
        if data == "" || otherData == "" {
        }
    } catch (err) {
        return errors.Label("fix it", err)
        // Aside: why not add Label() to the error package?
    }
}

私はこれに反対する議論を考えました。このように書くと、そのcatchブロックを変更すると、より深いスコープのコードに意図しない影響を与える可能性があります。 これは、 try...catch発生するのと同じ問題です。

単一の関数の範囲内でのみこれを実行できる場合、リスクは管理可能であると思います。おそらく、エラー処理コードの多くを変更しようとするときに、エラー処理コードの行を変更するのを忘れるという現在のリスクと同じです。 これは、コードの再利用の結果と、DRYに従わなかった場合の結果（つまり、彼らが言うように無料の昼食がない）との同じ違いだと思います。

編集：私の例で重要な動作を指定するのを忘れました。 ?がcatchないスコープで使用されている場合、これはコンパイラエラーであると思います（私が最初に考えたのは確かにパニックをスローするのではなく）

編集2：クレイジーなアイデア：おそらくcatchブロックは制御フローに影響を与えないでしょう...それは文字通り、エラーが発生した後、 catch { ... }内のコードをコピーして行に貼り付けるようなものです? ed（完全ではありません-それでも独自のスコープがあります）。 私たちの誰もがそれに慣れていないので奇妙に思えます、それでそれがこのように行われるならばcatch間違いなくキーワードであるべきではありません、しかしそうでなければ...なぜですか？

@mewmew 、エラー処理の制御フローの側面についてこの問題を維持しましょう。 エラーのラップとアンラップの最適な方法については、制御フローとほぼ直交しているため、他の場所で説明する必要があります。

さて、このスレッドを維持してフローを制御しましょう。 ポイント3の具体的な使用法に関連する問題であるという理由だけで追加しましたが、追加のコンテキスト情報とともにエラーが返されます。

@jbaエラーのコンテキスト情報のラッピング/アンラッピングに特化した問題を知っていますか？

私はあなたのコードベースに精通しておらず、自動リファクタリングだと言っていたと思いますが、なぜEOFにコンテキスト情報を含める必要があったのですか？ 型システムではエラーとして扱われますが、EOFは実際のエラーではなく、実際にはシグナル値です。 特にio.Readerの実装では、ほとんどの場合、これは期待値です。 エラーがio.EOFでない場合にのみエラーをラップすることであった方が、より良い修正ではないでしょうか。

@DeedleFake少し詳しく説明することはできますが、トピックにとどまるために、エラーのコンテキスト情報のラッピング/アンラッピングに関する前述の問題でそうします。

私がすべての提案（私のものを含む）を読めば読むほど、goでのエラー処理に実際に問題があるとは思いません。

私が欲しいのは、エラーの戻り値を誤って無視するのではなく、少なくとも強制するための強制です。
_ := returnsError()

これらの問題を見つけるためのツールがあることは知っていますが、言語の第1レベルのサポートでいくつかのバグを見つけることができます。 エラーをまったく処理しないことは、私にとって未使用の変数を持っているようなものです-これはすでにエラーです。 また、エラーリターン型を関数に導入する場合、すべての場所で処理する必要があるため、リファクタリングにも役立ちます。

ここでほとんどの人が解決しようとしている主な問題は、「入力量」または「行数」のようです。 行数を減らす構文には同意しますが、それはほとんどがgofmtの問題です。 インラインの「単一行スコープ」を許可するだけで、問題ありません。

タイピングを節約するためのもう1つの提案は、ブール値のように暗黙的にnilチェックすることです。

err := returnsError()
if err { return err }

あるいは

if err := returnsError(); err { return err }

これは、すべてのポインタータイプの原因で機能します。

私の考えでは、関数呼び出しとエラー処理を1行に減らすと、コードが読みにくくなり、構文が複雑になります。

読みにくいコードとより複雑な構文。

冗長なエラー処理のため、すでに読みにくいコードがあります。 その冗長性を隠すことになっている前述のScannerAPIトリックを追加すると、さらに悪化します。 より複雑な構文を追加すると、読みやすさが向上する可能性があります。つまり、最終的にはシンタックスシュガーが何のためにあるのかということです。 そうでなければ、この議論には意味がありません。 私の意見では、エラーをバブリングし、他のすべてに対してゼロ値を返すというパターンは、言語の変更を正当化するのに十分一般的です。

エラーをバブリングし、すべてに対してゼロ値を返すパターン

19642はこれを簡単にします。

また、経験報告をしてくれた@mewmewに感謝します。 特定の種類のエラー処理設計における危険性に関連する限り、これは間違いなくこのスレッドに関連しています。 これらをもっと見たいです。

自分の考えをうまく説明できていないので、要点を作成しました（そして気付いたばかりの欠点の多くを修正しました）

https://gist.github.com/KernelDeimos/384aabd36e1789efe8cbce3c17ffa390

この要点には複数のアイデアがあるので、それらを別々に議論できることを願っています

ここでの提案は明示的にエラー処理に関するものでなければならないという考えを少し脇に置いて、Goがcollectステートメントのようなものを導入した場合はどうなるでしょうか。

collectステートメントはcollect [IDENT] [BLOCK STMT]の形式になります。ここで、identはnilタイプのスコープ内変数である必要があります。 collectステートメント内で、特別な変数_!が、収集される変数のエイリアスとして使用できます。 _!は、 _と同じように、割り当てとして以外は使用できません。 _!が割り当てられると、暗黙のnilチェックが実行され、 _!がnilでない場合、ブロックは実行を停止し、残りのコードを続行します。

理論的には、これは次のようになります。

func TryComplexOperation() (*Result, error) {
    var result *Result
    var err error

    collect err {
        intermediate1, _! := Step1()
        intermediate2, _! := Step2(intermediate1, "something")
        // assign to result from the outer scope
        result, _! = Step3(intermediate2, 12)
    }
    return result, err
}

これは

func TryComplexOperation() (*Result, error) {
    var result *Result
    var err error

    {
        var intermediate1 SomeType
        intermediate1, err = Step1()
        if err != nil { goto collectEnd }

        var intermediate2 SomeOtherType
        intermediate2, err = Step2(intermediate1, "something")
        if err != nil { goto collectEnd }

        result, err = Step3(intermediate2, 12)
        // if err != nil { goto collectEnd }, but since we're at the end already we can omit this
    }

collectEnd:
    return result, err
}

このような構文機能が可能にする他のいくつかの素晴らしいこと：

// try several approaches for acquiring a value
func GetSomething() (s *Something) {
    collect s {
        _! = fetchOrNil1()
        _! = fetchOrNil2()
        _! = new(Something)
    }
    return s
}