orange
さんがブースト
「最後のエラーを得る」系統、いくらか問題が知られていて、
・皆面倒がって誰も明示的にエラーチェックしなくなる
・エラー処理までの間に何かやっておきたいことがあった場合、暗黙の「最後のエラー」が上書きされてしまうことがある
・誰が「最後のエラー」を上書きするかが明示的でない(ドキュメントに書いてなければソースを読むしかない)
などがある
orange
さんがブースト
オレンジ氏の話、古の errno とか glGetError() みたいなのを彷彿とさせてなんだか体調が悪くなってきた(過言)
golang継承ないっぽいを考慮するとこんな感じ？＞＜；
Fuga();
if (lasterror != null)
{
if (lasterror.Message == "TekitounaError")
{
Console.WriteLine("てきとうなえらー！＞＜；");
}
lasterror = null;
}
golang、継承が無いらしい（？）からこういう風にできるのかわかんないけど・・・＞＜
・・・それを例えばこう省略出来ればいいような？＞＜
Fuga();
if (lasterror != null)
{
if (lasterror is TekitounaError)
{
Console.WriteLine($"てきとうなえらー！＞＜；{lasterror.Message}");
}
}
C# で言うとこんな感じに・・・＞＜
Exception lasterror = null;
try
{
Fuga();
}
catch (Exception ex)
{
lasterror = ex;
}
if (lasterror != null)
{
if (lasterror is TekitounaError)
{
Console.WriteLine($"てきとうなえらー！＞＜；{lasterror.Message}");
}
}
orange
さんがブースト
ていうか絶対返すのであれば、暗黙に予約語で返って来るみたいななんかそういう方がいいような気が・・・＞＜（例えばlasterrorって言う予約語（予約変数？＞＜；）の中身を見ればおｋ方式とか・・・＞＜）
orange
さんがブースト
そもそもerrorを絶対に返せみたいなのを感じる
例えば、雑すぎるけどこんな感じとか＞＜； errが何かチェックされない＞＜（人間から見た時に（広義の）型安全じゃないみたいな＞＜）
func Hoge() int {
err := Fuga() //実は返ってくるのはerrorじゃ無い
if err != nil {
return 0 //エラーの時は0を返そう＞＜
}
return 1
}
こういう場合には、return errの所で型チェックされるだろうけど、そうじゃない場合チェックされる事が無くない？＞＜
func Hoge() error {
err := Fuga()
if err != nil {
return err
}
...
return nil
}
オレンジ的そもそも謎なのは、 errの型がerrorって型である保障が全く無いコードになってない？＞＜；って疑問が＞＜；
orange
さんがブースト
Big Sky :: golang で複数のエラーをハンドリングする方法 https://mattn.kaoriya.net/software/lang/go/20140416212413.htm
これとかはどうだろうか
オレンジならどういう仕様にするか？＞＜；って考えた結果、暗黙にエラー用の型で宣言されてる変数を用意するという方式を思いついた・・・＞＜（でも、なんかエレガントじゃない＞＜；）
orange
さんがブースト
例の1033F https://youtu.be/-VuHZZf6wn8
今日乗ったドレミファのやつです
golangのエラー、エラーオブジェクト？＞＜が返ってくるかどうかどうしてわかるの・・・？＞＜；（型推論のせいで『必ずそれが例外である』とは限らないコードになっちゃってない？＞＜；）
よくわからない・・・＞＜
-- なぜGo言語はエラー返却に例外機構を使わないのか - 嵐の小舟より https://tmrtmhr.info/tech/why-does-golang-not-have-exceptions/
タプルでどうにかする方式？＞＜
Go言語のエラーハンドリングについて - Qiita https://qiita.com/nayuneko/items/3c0b3c0de9e8b27c9548
orange
さんがブースト
golang、無限に `if err != nil` みたいなのを書いてる
- ＠orange_in_space
2017年 4月に登録
