そう！＞＜；（オレンジは簡潔に説明できなかった＞＜；）
orange
さんがブースト
ああ、ユーザが根本的に型を履き違えている場合にエラーにしてやりたいという文脈なんですね、把握しました
「型推論のせいで、エラーじゃない型の変数をエラーの型だと思ってしまう現象を起こさないようにするにはどうすればいいのか？＞＜」っていう・・・＞＜（オレンジは型推論を極端に嫌ってるから、（C# とかでは）型推論まず使わないから別にあれだけど＞＜；）
オレンジがその方式が好きってことじゃなく、golangが「例外処理を言語仕様に入れたくない」って言ってるのをどうにかこうにかマシにするには的な感じの・・・＞＜；
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_in_space
2017年 4月に登録
