Goを書いていてrecoverを使うことはまずほとんどない。頻繁にrecoverを書いているとしたらなにかが間違っているのでプログラミングスタイルを見直すこと。 Goでのエラーハンドリング Effective Goなどで説明されているように、Goではエラーは関数の返り値として返される。たとえばio.ReaderのRead関数は、読み込んだバイト数と、（nilかもしれない）エラーの2つの値を返す。Goでは基本的に、エラーは常にこういう通常の値としてハンドルするべきで、エラーの時のための特別な制御構造（try 〜 catch）のようなものを使うのは、利点より害のほうが多いという考え方をとっている。 （同じような考えで例外を使用禁止にしている大規模C++プログラムはいくつもある。たとえばChromiumなどはそうだ。LLVM/Clangもパフォーマンス上の問題で例外を使っていない。C++コンパイ
Go で関数の戻り値のエラーを判別するときに、エラーメッセージの文字列をチェックするコードが存在します。 (例) これは、 Go が言語設計としてエラー処理が貧弱だったり、標準ライブラリがエラー処理を軽視しているからでしょうか？ 言語設計や標準ライブラリのAPIの設計をみて行きましょう。 TL;DR 言語設計としては、Java的例外機構と同等以上の（文字列比較によらない）エラー検査が可能 ただし Go のエラーに関する哲学により、公開されていないエラーが多い 実際にエラーを文字列比較されている実例についての解説 Go のエラー検査方法 Java の例外機構では、例外をキャッチするために専用の構文が用意されており、型によりマッチングすることができます。 これはクラスのツリー構造を利用してサブクラスをまとめて分岐することもできます。 一方で、同じクラスでも値によりエラー処理が異なる場合には、
tl;dr panic時ではなくerror時にもfullのstack traceが欲しい pkg/errors が便利 はじめに しばらくgoを書いていて、使い捨てのコードのエラー処理についてどうすれば良いのか考えたりしていた。ここで言う使い捨てのコードというのは1ファイル位で作れそうな小さなコマンドラインのコマンドのようなものを指している。 まともなアプリケーションコードでは考えることが色々ある気がするけれど。使い捨てのコードなら以下を満たしていれば十分だと思った。 終了ステータスが0以外になる エラーの発生箇所が正確に分かる(stack trace) 前者はテキトーに書いても自然に満たす気がする。ここでは後者をどうするかについて書く。 panic時は問題なし。ただしerror時には問題がある ここでいうエラー処理は以下の２つを含んでいる。 panic時の処理 error時の処理 テキト
Andrew Gerrand 12 July 2011 Introduction If you have written any Go code you have probably encountered the built-in error type. Go code uses error values to indicate an abnormal state. For example, the os.Open function returns a non-nil error value when it fails to open a file. func Open(name string) (file *File, err error) The following code uses os.Open to open a file. If an error occurs it call
You can find (just about) anything on Medium — apparently even a page that doesn’t exist. Maybe these stories will take you somewhere new?
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
