質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Go

Go(golang)は、Googleで開発されたオープンソースのプログラミング言語です。

Q&A

解決済

2回答

469閲覧

golangのエラー処理について

puroko3

総合スコア185

Go

Go(golang)は、Googleで開発されたオープンソースのプログラミング言語です。

0グッド

1クリップ

投稿2019/01/25 10:33

編集2019/02/02 11:40

質問1
error 以外の戻り値の値はどうするべきですか?

go

1package main 2 3import ( 4 "fmt" 5) 6 7func g(n int) (int, error) { 8 if n == 3 { 9 return -1, fmt.Errorf("エラー") 10 } 11 return n + 1, nil 12} 13 14func main() { 15 n, err := g(3) 16 fmt.Println(n, err) 17}

このコードの場合は、intの戻り値です。
その関数が本来であれば、0以上の整数しか返さないのであれば-1に、文字列であれば空文字にしているのですが、あらゆる整数や空文字を含む文字列を返す可能性がある場合は、どういう値にするべきなのでしょうか?

またarrayやsliceはnilにしてますが、問題ないですか?
どうするべきかではなく、どうしてるかでもいいので意見がほしいです。

質問2
ライブラリ側のエラーチェックをする場合は、panicを積極的に使ってもいいですか?

ライブラリのロジックが正しい限り、ユーザー側のerrorチェックがnilにしかならないような場合です。

追記

go

1package main 2 3import ( 4 "fmt" 5) 6 7func Add(x, n int) (int, error) { 8 if n < 0 { 9 return 0, fmt.Errorf("0より小さい値が入力された") 10 } 11 return x + n, nil 12} 13 14func Add10(x int) int { 15 result, err := Add(x, 10) 16 if err != nil { 17 panic(err) 18 } 19 return result 20} 21 22func main() { 23 fmt.Println(Add(10, 5)) 24 fmt.Println(Add10(10)) 25}

func Add func Add10共にユーザー側に公開するものとします。
Addの方は、ユーザーが間違った引数を渡したらエラーを返すのに対して
Add10の方は開発者が正しい引数を渡している限りはエラーが起きる事はありません。
今回の場合は、簡単な処理なので正しい引数が渡されている前提でもいいと思いますが、もう少し複雑な処理になってくるとエラーをアンダースコアで潰さずに念の為チェックをしたいという時があります。
だからと言って戻り値で返すと、ライブラリのロジックが正しい限り不要なエラーチェックをさせる事になってしまいます。

こういった場合はどうするべきなのでしょうか?

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答2

0

私も、Go について初心者なので、解説書をざっくり読んだ上での当てずっぽうの回答をさせていただきます。

関数の返り値の型が (int, error) で、error が non-nil の場合、int の方は、int のゼロ値である 0 とするのが一般的なような気がします。

同じように、slice の場合は、slice 型のゼロ値である nil に、array の場合、例えば [3]int 型なら、そのゼロ値である [0, 0, 0] にすると良いのではないでしょうか?

でも、全くの当てずっぽうです。すみません。

投稿2019/01/25 14:49

kts_h

総合スコア207

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

puroko3

2019/01/28 07:26

なるほど、全てゼロ値にする感じですか 参考にさせていただきます。
guest

0

ベストアンサー

質問2だけ回答します。

ライブラリ側のエラーチェックをする場合は、panicを積極的に使ってもいいですか?

基本panicはどこかで基準を設けて積極的利用は控えたほうが良いかと思います。
ライブラリ利用者がpanicを想定しなければならない利用方法はNGです。
提供するライブラリ内で必ずrecoverして通常のエラーハンドリングに乗せる場合に限り利用しても良いという考え方が一般的です。

ライブラリのロジックが正しい限り、ユーザー側のerrorチェックがnilにしかならないような場合です。

「ユーザー側のerrorチェックがnilにしかならないような場合」はerrorを返すのが不要なので関数・メソッドの定義の返値にerrorを含めない方向で検討するといいと思います。

投稿2019/01/29 01:17

nobonobo

総合スコア3367

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

puroko3

2019/02/02 11:48

回答ありがとうございます! 今回の場合は、ライブラリ利用者がパニックを想定しなければならないと言えるのでしょうか? ライブラリにバグが残っていれば、パニックが起きてしまいますが、バグがないのであればパニックは想定しなくてもいいので... 質問の方に一例を追加しました。やはりこれでもパニックは使うべきではないのでしょうか?
nobonobo

2019/02/05 00:12

Add10のようにエラーにならない事がはっきりしている場合はAddが返すエラーを無視するのはアリだと思います。エンバグ対策としてpanicを入れるのも良いでしょう。 しかしAddのロジックが複雑になって自明でなくなってきた場合や別パッケージになる場合にはやはりエラーを上層に伝搬させておく方がベターでしょう。 Add10利用者がトラブルがあるのなら区別したくなるからです。 なのでAddが同じファイル上に存在しこれ以上要件が変化しない事がはっきりしてるならアリです。少しでもAddを別パッケージに置くとかロジックを変更する可能性が残っているのならナシです。 個人的にはよほど自明(1箇所追えばエラーにならない事がはっきりする)でなければエラーを伝搬させるように実装します。 panicを使うとしたらMust関数経由のパッケージグローバル変数初期化かinit関数内でのエラーくらいかな。(カバレッジゼロのテスト実行でも必ず検出できるパターンのみ)
puroko3

2019/02/10 06:54

回答ありがとうございます。 簡単な時であればpanicありって感じなんですね。 また機会があればよろしくお願いします。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問