[過去ﾛｸﾞ]
Go language part 3 (1002ﾚｽ)
Go language part 3 http://mevius.5ch.net/test/read.cgi/tech/1571315884/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
必死ﾁｪｯｶｰ(本家)
(べ)
自ID
ﾚｽ栞
あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
6: デフォルトの名無しさん [sage] 2019/10/18(金) 13:53:47.66 ID:wgxHvfCr 先週から仕事でGoやることになったんだが、この言語辛すぎないか・・・？ ジェネリクスないしエラーが辛い。ジェネリクスは2.0で入るらしいが。 Goの作法だとエラーハンドリング忘れて次の処理を書けるリスクが常に孕んでてて書いてて全然安心できない。 あと詳細なエラー情報見ようとするとcustomErr,ok:=err.(CustomError)みたいにしないと情報とれないの危なすぎでしょ。 なんでカスタムエラー型認められていないの？ http://mevius.5ch.net/test/read.cgi/tech/1571315884/6
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
12: デフォルトの名無しさん [sage] 2019/10/18(金) 19:57:12.19 ID:wgxHvfCr まあRustも関数型言語かというと違うけどな。標準ライブラリにはモナドないし。 ジェネリクスが必要なものに関しては今使えないから仕方がない面はあるとは思う。 ただカスタムエラー型が実質使えない状態になってるのは辛いなあとは思う http://mevius.5ch.net/test/read.cgi/tech/1571315884/12
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.027s