[過去ﾛｸﾞ]
Go language part 3 (1002ﾚｽ)
Go language part 3 http://mevius.5ch.net/test/read.cgi/tech/1571315884/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
8: デフォルトの名無しさん [sage] 2019/10/18(金) 14:31:17.21 ID:I27oYfOd >>6 エラー処理を忘れるうっかりさんは例外だってキャッチ忘れるだろな そして、エラー処理は1.13でほんの気持ちだけ改修入ってるからチェック Is, As http://mevius.5ch.net/test/read.cgi/tech/1571315884/8
10: デフォルトの名無しさん [sage] 2019/10/18(金) 15:49:30.94 ID:wgxHvfCr >>7 認められてないというよりか風潮といった感じか カスタムエラーがstructじゃなくてinterfaceならいけるんじゃない？ まあどのみち使用しているライブラリがerror返してるからどうしようもないんだけどな 俺はMySQLのエラー番号が知りたいだけなのにどうして危険な操作を強いられるんだ >>8 まず俺はGoのエラーと例外を引き合いに出してはいない(例外は糞だが) 例えば関数の戻り値がT,errorのような場合でerrorじゃないときだけTの戻り値にアクセスできるような仕組みが欲しい ScalaのEitherやRustのResultのようなやつな 今はジェネリクスないからそういう実装はできないだろうけど そもそも職場の制約で.1.13は使えないが、IsもAsも対してかわらんなって印象だわ。 ライブラリの実装者が中で返すエラーの型を変えた場合、IsやAsしててもコンパイルエラーにならず適切なエラー処理ができずに実行されてしまう。 戻り値の型できちんとカスタムエラー型を明示してくれてればコンパイルエラーで気づけるんだけどな 今さっき聞いたんだけど、2.0で入る予定のエラーハンドリング周りのサポート、error型のみが対象らしいんだってな。 2.0にはいると本当にカスタムエラーの道が閉ざされてしまいそうだけど本当にそれでええんやろか http://mevius.5ch.net/test/read.cgi/tech/1571315884/10
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.038s