次世代言語9[Haskell Rust Kotlin TypeScript Dart]

**デフォルトの名無しさん** · 2018/03/06(火) 10:09:15.60

スレタイ以外の言語もok

前スレ
次世代言語Part8[Haskell Rust Kotlin TypeScript]
http://mevius.5ch.net/test/read.cgi/tech/1512137301/

**デフォルトの名無しさん** · 2018/04/08(日) 09:00:51.10

Cのprintfの戻り値を毎回欠かさずチェックしてる人だけが例外に石を投げなさい

**デフォルトの名無しさん** · 2018/04/08(日) 10:19:07.88

戻り値の握り潰しは局所的・静的に判断できるけど例外はそうじゃないからなぁ。
それこそ例外を起こしてみないと見つけるのが困難だったりして。

**デフォルトの名無しさん** · 2018/04/08(日) 10:23:53.74

例外は継続的な改良に対応しやすいのがメリットなんだよな
取りあえず最初は例外安全だけ意識して例外は上の方でまとめて処理しておいて、
あとでより丁寧な取扱いが必要になったときは問題なく対応できる
もちろん、検査例外とかいうビチグソは無い前提だが

**デフォルトの名無しさん** · 2018/04/08(日) 11:36:37.63

最初はexit
exitの握り潰しが必要になったら例外で

**デフォルトの名無しさん** · 2018/04/08(日) 11:42:04.86

>>758
1から10までの整数を足すのに
ループで順番に足す方法を教える様なのが
今の日本のプログラミング学習(教育)だからな
そんなんじゃだめ

**デフォルトの名無しさん** · 2018/04/08(日) 13:08:16.40

このスレも例外が理解できない幼稚園児ばっかかよ
Goみたいな言語が流行るわけだ

**デフォルトの名無しさん** · 2018/04/08(日) 13:22:55.27

自分で選んだ言語がそれだったらそれでもいいよ
より良い言語を後で見つけたら自分が馬鹿だっただけで済む
しかしそれを選んだのが会社や国家だったら馬鹿にしても炎上するし擁護しても炎上する

**デフォルトの名無しさん** · 2018/04/08(日) 13:39:52.93

このスレの議論はほんとレベルが低いな
間違った使い方をしたときどちらがマシかでしか優劣をつけられないのか

**デフォルトの名無しさん** · 2018/04/08(日) 13:50:33.26

>>782
なんか会話が噛み合わないなと思ってたがやっと理由が分かった気がする。
>>782の言う"どこ"はGoのエラー(戻り値)は握りつぶしがしやすいから
誰が"どこ"でエラーを握りつぶすコードを書くか分からないって意味の"どこ"だよね。
俺の言う"どこ"は例外がスローされた場所に対して
キャッチされる場所が"どこ"か分からないって意味の"どこ"なんだよ。
キャッチされる場所が分からないとデバッグ時に探すのが面倒なんだよ。
Goみたいに戻り値としてエラーが返されるとエラーの発生場所と
握り潰した場所は必ず一致するからデバッグしやすい。
結局、従来の例外はgoto文と同じでフローが飛ぶから気持ち悪いってのが俺の意見。

**デフォルトの名無しさん** · 2018/04/08(日) 14:09:14.32

従来の言語にはexitがあるから例外がない
SmalltalkやJavaScriptにはexitがないから例外があるんだろう

**デフォルトの名無しさん** · 2018/04/08(日) 14:12:58.97

>>791
でも、次世代言語って間違った使い方(プログラマによるミス)をさせないように
制限をかける意味合いが強くない？Null安全とかその典型だと思うんだけど。
オレは絶対に使い方を間違えないって言うんならC++, C#とかを使ってろよってなるし…

**デフォルトの名無しさん** · 2018/04/08(日) 14:13:54.54

>>792
戻り値のエラーを握りつぶされると、不適切な状態で動き続けるから、デバッグが困難になると思うんだが。
例外の握りつぶしでも同じ事だけど、構文としては、例外の握りつぶしの方が見つけやすいと思うけどね。catchブロックでしか細工できないから。
goだと正常な返り値の隣に,_つけるだけで握りつぶせちゃうから、見つけづらいんじゃないかな。

**デフォルトの名無しさん** · 2018/04/08(日) 14:15:23.81

間違えを考慮しないシステムの恐ろしさを全くわかってない奴はそもそも話にならん。
プログラミングを語る資格がない。

**デフォルトの名無しさん** · 2018/04/08(日) 14:23:41.21

>>795
すまん。よく考えると確かにデバッグはどっちも面倒なことに変わりないわ。
ただ、個人的にはtry-catchも,_もどっちも見つけづらさは大して変わらないと思ってる。
デバッグ時じゃなくて、普通にコードを読むときに戻り値でやったほうがフローを把握しやすいってことが言いたかった。

**デフォルトの名無しさん** · 2018/04/08(日) 14:26:14.02

返り値でエラーを判別するコードだと、本来やりたいことの次にほぼ必ず、エラー判定処理が入るから、可読性が低いんだよね。
昔、C使ってた頃は、そういうところが嫌でたまんなかったし、ひどいのになると主要な処理が全部、条件部分で行われてて、if文の連なりしかないコードとかみたし。
正常系をリーダブルに書くには、例外の方が気持ちいいなと思うよ。

**デフォルトの名無しさん** · 2018/04/08(日) 14:32:30.43

そのあたりはEitherが良いと思うんだな

**デフォルトの名無しさん** · 2018/04/08(日) 14:35:54.54

後、最近のIDE使ってると、todoをコメントに入れとけば、あとでそれを、まとめて見直せるから、取り敢えず、try-catchして、catchのところはtodoにしといて、まず正常系を一通り買いてから、あとで異常系に対処するっていうワークフローにできるのが、例外の利点かなと思う。

**デフォルトの名無しさん** · 2018/04/08(日) 14:37:10.66

>>792
デバッグ時に、どこかでエラーが握りつぶされてるかもしれない、というパターンを考えないといけない、という意味で「どこ」
しかもそういう状況は>>795の言うように不適切な状況で動き続けるから
握りつぶした箇所と不具合の発生箇所がかけ離れることも多い
だから、goに限ったことではないが、エラーや例外の握りつぶしはデバッグしづらい
例外がどこでcatchされてるか探すのは、握りつぶし探しに比べたらまだ簡単

**デフォルトの名無しさん** · 2018/04/08(日) 14:37:23.36

>>799
タグ付きユニオンがある言語ならそれが一番だと思う。
前にも言ったけど、エラーハンドリングに関してはRustのResult型が一番筋がいいと思ってる
でも、Goにはタグ付きユニオンがないからなあ…

**デフォルトの名無しさん** · 2018/04/08(日) 14:51:49.81

goは本格的には使ったことないけど、無視はできないんで、いろんなコードを見てるんだけど、今のところの感想としては、goって、書き手の思考を遮らないというところに重きを置いてる印象。
deferなんか、なんか開いたらあとで閉めるけど、忘れない内にその処理を予約しとこうみたいな発想かな。
自分は書くことより読むことを重視するタイプなんで、あまりgoには向いてないなあと思ってる。

**デフォルトの名無しさん** · 2018/04/08(日) 14:51:50.04

副作用禁止ならexitも例外も禁止だからEitherがある

**デフォルトの名無しさん** · 2018/04/08(日) 15:22:23.64

stack traceもしらんのか

**デフォルトの名無しさん** · 2018/04/08(日) 15:29:06.45

握りつぶしてるところでスタックトレース出力するんだよ！

('､3_ヽ)＿？？

**デフォルトの名無しさん** · 2018/04/08(日) 15:51:49.24

maybe, eitherがある言語やった後に無い言語はしんどい

**デフォルトの名無しさん** · 2018/04/08(日) 17:20:17.22

Maybe, Eitherは強い。ほぼ必須な体になってしまった

**デフォルトの名無しさん** · 2018/04/08(日) 17:47:41.66

Eitherは初見だとそれがエラー処理用によく使うっていうことが
名前から全然伝わってこないところだけが嫌い

**デフォルトの名無しさん** · 2018/04/08(日) 17:58:42.79

>>803
書きやすさと読みやすさは同一だと思ったが。特にdeferとか大体close処理では？
open直後はdeferにclose処理書いてあったほうが読みやすくないかな？

**デフォルトの名無しさん** · 2018/04/08(日) 17:58:46.39

たし蟹

**デフォルトの名無しさん** · 2018/04/08(日) 18:04:30.90

リューナイト

**デフォルトの名無しさん** · 2018/04/08(日) 18:14:07.95

defer はスコープの終わりで暗黙的に動くクラスのデストラクタより
コード部分で明示した方がわかりやすくね？って発想じゃないかね。
こういうのは好みだったり書いてるアプリの種類で分かれそうな気はする。

**デフォルトの名無しさん** · 2018/04/08(日) 18:50:09.38

c++17の [discard]はどうかね？

**デフォルトの名無しさん** · 2018/04/08(日) 18:52:29.42

間違えた nodiscard

**769,815** · 2018/04/08(日) 23:39:43.80

>>792
> Goみたいに戻り値としてエラーが返されるとエラーの発生場所と
> 握り潰した場所は必ず一致するからデバッグしやすい。

俺もそれには同意で、更に一歩すすんでc++17の nodiscard属性みたいな指定ができるてほしいんだよ。デフォルトはコンパイルエラーで。

**デフォルトの名無しさん** · 2018/04/09(月) 00:41:14.72

Fortran のIO関係のエラー処理は優れてると思うわ。
Open文にoptionalのerr引数を渡して置けば、エラーが出てもerrに値を入れて続行。err引数を渡してなかったらエラーが出たら異常終了

**デフォルトの名無しさん** · 2018/04/09(月) 00:59:36.33

goのdeferは、その中で起こったエラーを外に通知する(簡単な)方法がないってんで
槍玉に上げられてなかったっけ？うろ覚えだけど

**デフォルトの名無しさん** · 2018/04/09(月) 01:32:15.01

>>818
一番簡単な方法は名前つきreturn変数を使うことだから簡単ちゃ簡単
だが正直名前つきreturn変数がそもそもクソ構文

**デフォルトの名無しさん** · 2018/04/09(月) 06:40:40.00

>>817
異常終了してはならないUIもある
UIが言語に影響を与える

**デフォルトの名無しさん** · 2018/04/09(月) 07:57:09.29

>>819
はー、名前付きreturn変数なんてあったんだ
しかし本来の流れによるerrがある場合は握りつぶさないようにしないといけないし、真面目にやると分岐が入り組みそうだな

**デフォルトの名無しさん** · 2018/04/09(月) 07:59:50.20

>>820
いやそのためにerr引数があるのよ……

**デフォルトの名無しさん** · 2018/04/09(月) 08:27:01.39

>>816
MSはかなり昔からそういうの力を入れていて独自仕様で実現してるな。(SAL注釈)
SDKのヘッダなんかで見かける _Check_return_ とかとかいうやつ。VSの「コード分析」でチェックしてくれる。

**デフォルトの名無しさん** · 2018/04/09(月) 08:42:34.03

理想はエラーハンドリングを書いてなかったらコンパイルエラー。
(エラーハンドリングでエラー握り潰すやつは流石にそこまで面倒見きれない)
次点は強制終了。その際にエラーがどこで何故起きたのかって情報を出せること。
一番悪いのはそのまま処理進んでサイレントクラッシュ。

こんな感じ。

**デフォルトの名無しさん** · 2018/04/09(月) 08:51:45.67

コンパイルエラーは、そこまで強烈にエラー対応必須にしたらスクリプトみたいな「まずはとりあえず動くコードを書いて様子を見る」っていう使い方は出来なくなるな

**デフォルトの名無しさん** · 2018/04/09(月) 09:45:04.94

となるとrustやな

**デフォルトの名無しさん** · 2018/04/09(月) 09:59:14.65

そういやClojureってどうなったん？

**デフォルトの名無しさん** · 2018/04/09(月) 10:18:17.46

Goの名前付きreturn使うとアセンブリまで落としたとき、コードが少しきれいになるぞ。
俺は好き。

**デフォルトの名無しさん** · 2018/04/09(月) 10:48:34.89

>>828
返値の最適化だけが目的なら初めからresult変数方式のやつ使えば
Pascal、Eiffel、あとFortranもそうだぞ

**デフォルトの名無しさん** · 2018/04/09(月) 11:33:31.90

デバッグは自分との戦い
だが最適化は自分が速くならなくても相手が遅くなれば勝てる
他人の足を引っ張る要素があるからカオスになる

**デフォルトの名無しさん** · 2018/04/09(月) 12:00:22.27

>>829
だけが目的と言うか、優劣をつけたりGoを使う理由にはあんまりしてないが。

例外は俺も好きじゃないな。
ただのちょっと見た目のきれいなgotoであって、フローとしては全然きれいじゃないし、
finallyで複数のリソースの開放しようとしたらどこまで進んだか管理するしかなくなるし、
各エラーで細かい処理が必要だったら結局スコープの狭いtry-catch書くことになるし、
毎行errチェックしたり、いっそ無視したりするのとレベルが変わらん。

deferは、実際に使えた直後に開放を予約できるから価値がある。

良くできてると思うけどな。

**デフォルトの名無しさん** · 2018/04/09(月) 12:16:00.98

>>825
そこは、エラー戻値無視するな構文を用意してれば良い

**デフォルトの名無しさん** · 2018/04/09(月) 12:16:21.64

>>829
え、すまん。よく知らないんだけど、Fortran って関数で配列を返してもサブルーチン的ないい感じに最適化してくれるの？

**デフォルトの名無しさん** · 2018/04/09(月) 13:04:43.93

>>833
されるよ。全部の実装でそうとは断言できないけど
要するに>>697のretvalが直接返り値用の変数として見えるってだけ

**デフォルトの名無しさん** · 2018/04/09(月) 14:38:02.08

何でここの人たちエラーをその場で処理するのが当然だと思ってるの？
普通は上に投げるよね？

**デフォルトの名無しさん** · 2018/04/09(月) 14:47:49.87

>>835
その「上」の関数ではどうすんの？また上に投げるの？

**デフォルトの名無しさん** · 2018/04/09(月) 15:03:10.07

一番上のハンドラでまとめて受け取る

**デフォルトの名無しさん** · 2018/04/09(月) 15:18:43.79

結局人類にgotoは必要だったんだ！

**デフォルトの名無しさん** · 2018/04/09(月) 16:05:31.09

なんで2ちゃんでこういう議論をすると最期は必ずアホアホ展開になるの？

**デフォルトの名無しさん** · 2018/04/09(月) 16:19:21.64

>>835
俺は、その上側でのエラーハンドリングを必須にすることができて欲しいという意見。c++17の nodiscardみたいなの。
rustのResult型や他言語のEither勉強不足でわからない。スマヌ

**デフォルトの名無しさん** · 2018/04/09(月) 16:26:17.23

>>835
マルチスレッドが普通になったから
上に投げるよりスレッドの外に投げる

**デフォルトの名無しさん** · 2018/04/09(月) 16:39:51.89

rustのResultは検査しないとコンパイラにワーンされるよ

**デフォルトの名無しさん** · 2018/04/09(月) 18:13:02.99

>>835
上に投げるとしても、戻り値で明示的に戻せば良いだろう。
とりあえず手に負えないからだれか呼んだ人処理して、って言って、だれの手にも負えない可能性がある、ってのは良くないと思うよ。
普通とか言い始めると誰の普通かはっきりしないから、それはおいといて。

goでも、ホントに戻り値なしで呼ぶとき以外(何かしらの値とともにエラーが帰ってくる時)は、_で明示的に握りつぶさない限り受けた変数に触らないとコンパイル通らないし。
何一つ受けずに呼び出したり、触った結果握りつぶしたらコンパイルは通っちゃうけど。

**デフォルトの名無しさん** · 2018/04/09(月) 18:20:13.54

例外安全を徹底してればどこでキャッチしようが手に負えない例外なんか無いだろ
それを不安に感じるのは、個別の事情にばかり気を取られて全体の一貫性を疎かにする典型的な日本人の思考パターンだ
(メモリ不足など、どこでキャッチしても対処のしようがないものは除く)

**デフォルトの名無しさん** · 2018/04/09(月) 18:26:58.77

>>844
徹底する、というルールベースな時点で「手に負えない例外は存在しない」という事を言い切るのは不可能でしょ。
メインロジックではアプリケーションの総合ハンドラでメッセージ出してリトライさせれば手に負えるはずの例外だったが、
なんの因果かそいつがバッチプログラムに使われる事になった時とかなんて、前提条件や処理フロー自体が変わる典型だと思うが。

最初からエラーとして返しとけば、なんの問題もなく流用できるでしょ。
常に呼び出す親が(さらに親へ丸投げするかの選択も含め)処理することが義務付けられてるほうが明示的だよねって言ってるんだが。

**デフォルトの名無しさん** · 2018/04/09(月) 18:38:57.68

>>845
戻り値なら流用しやすいという根拠は？
なんとなく手抜きっぽい、で批判する典型的な日本人的思考だね

**デフォルトの名無しさん** · 2018/04/09(月) 18:44:44.78

チョンが何か言ってらぁｗｗ

**デフォルトの名無しさん** · 2018/04/09(月) 18:45:14.09

あと、例外機構を持つ言語には例外安全を維持するための仕組みが組み込まれているのが普通だから、
それを「運用ルールに頼っている」と切り捨てておきながら戻り値は言語の補助があるから安全だと主張するのはダブスタの詭弁だ

**デフォルトの名無しさん** · 2018/04/09(月) 18:45:52.21

>>846
書いてるだろ。
明示的に処理するからだよ。
すっぽぬけて何処か別の定義されている「はず」のハンドラに任せない所。

全関数にtry-catchを書いてて、親にもtry-catchが漏れなくあって、明示的に再throwしてたり、異常な場合はちゃんと死ぬ事が保証できてるなら、それでもいいけど。
この関数では呼び出し先がthrowすることもあるけど、親にハンドラがあるから大丈夫、が一箇所でもあったら認めないが。

何か、戻り値でエラーを返せる言語使ったことある？
パターンマッチングでエラーか結果か判定できたり、複数結果を返せたり、引数でエラーをどう処理するから指定できる言語。
使ったらわかると思うけど。

**デフォルトの名無しさん** · 2018/04/09(月) 18:50:39.85

>>848
ダブルスタンダードでもないよ。

維持するための仕組みがあったって、維持していると保証がない限り維持は出来てないのと同じでしょ。

recoverがあるから、catchできるのと同じだからエラーハンドラここに書くって言う奴と同類に見える。

**デフォルトの名無しさん** · 2018/04/09(月) 18:53:07.60

暗黙的に握りつぶす/無視する、か、明示的に握りつぶす/無視する、だけの違いなんだが。
なんでわかんないんだろう。

**デフォルトの名無しさん** · 2018/04/09(月) 18:53:14.64

>>849
そんなことはプログラミングのメインストリームがとっくの昔に通った道なんだよ
Javaの失敗をトレースしてるようにしか見えない
Javaの検査例外がなぜ失敗したかを調べてみたら？

**デフォルトの名無しさん** · 2018/04/09(月) 18:55:18.76

>>852
「そもそも例外があるから、こういう失敗するんだ」を「例外無くして明示的にやろう」
と言語仕様で厳しくやってるだけで、
トレースしているどころか、トレースしないように別ルート取ってるだろ。
どこがトレースしてるの？

**デフォルトの名無しさん** · 2018/04/09(月) 18:58:04.38

>>853
まさか検査例外を知らないのか？
あれは戻り値によるエラー処理を強制してるのと等価だよ
まずは勉強しよう

**デフォルトの名無しさん** · 2018/04/09(月) 18:58:52.48

日本人的だとか、ロジカルでない事をグダグダ言う前に、いろんな言語の言語仕様みてくりゃいいのに。
Fortranが話題に出てるけど、知ってんのかって疑問。

**デフォルトの名無しさん** · 2018/04/09(月) 19:03:27.06

>>854
知ってるよ。
非検査例外と検査例外のどちらも発生させうるメソッドはどうハンドリングするの？運用のルール？
結局全部検査例外なら良いって話になっちゃうし、throws書いたらガバガバになるだけじゃん。

**デフォルトの名無しさん** · 2018/04/09(月) 19:58:52.42

jsでasync await使おうとするとエラー系は例外扱いになるから辛い。

**デフォルトの名無しさん** · 2018/04/09(月) 20:15:00.84

>>855
Fortranを話題に出してるのは俺で、俺はFortranユーザーだ。なんか用か？

**デフォルトの名無しさん** · 2018/04/09(月) 20:15:41.91

まあ返り値の最適化はわかってなかったけどなｗ

**デフォルトの名無しさん** · 2018/04/09(月) 20:24:45.38

次世代語る前に現世代を勉強した方が良いねこれは。

**デフォルトの名無しさん** · 2018/04/09(月) 20:25:58.04

>>858
いやいや、そういう意味じゃない、誤解させてすまん。
引数でerrの取り扱いしたり、名前付き引数があったり、そういう言語を触ったことがあるのか？
皆はそれぞれ使ってて、メリットを分かって話してるが、自分(ID:2gnvm26g)は戻り値でそういう処理をする言語は触った事があるのか？
話題についてこれてるか？Javaかなんかの狭い世界の話ししてるんじゃないのか？
って事を言いたかったんよ。

**デフォルトの名無しさん** · 2018/04/09(月) 20:31:26.77

>>861
ああそういうことか。誤解してたわすまん

**デフォルトの名無しさん** · 2018/04/09(月) 20:39:58.68

>>861
俺は普通に使ったことあるし、戻り値をエラーに使うことを否定したつもりはないぞ？
ただ、あんたの主張はJavaの検査例外が失敗した理由を解決していない、と言ってるんだよ

**デフォルトの名無しさん** · 2018/04/09(月) 20:40:46.31

>>862
いやいや、俺の方こそすまん。
慌てて説明したから名前付き戻り値を名前付き引数とか言ってるし。
重ね重ね面目ない。

**デフォルトの名無しさん** · 2018/04/09(月) 20:40:53.09

例外設計に関してはrustが現状ベストだと思うけどな

>>857
unhandled promiss rejection出た時の絶望感半端ない

**デフォルトの名無しさん** · 2018/04/09(月) 20:45:47.57

>>863
解決していないんじゃなくて、結果として検査例外の書き方がまずかった、検査例外以外の存在も実は「これ検査例外にすべきじゃないの？」とか色々物言いもつく、
そもそも論として全部明示的にハンドリングする事をデフォルトにして、検査例外どころか例外を無くそう、って話なんだが。
失敗したも何も、クソめんどくさかったりして、throwsを全部につければ問題無いとか変なルールで回避するからややこしくなるだけなって、収拾がつかなくなったんでしょ。
ジェネリクスがない頃からJavaは触ってるし、歴史を知らんわけでもない。

問題を整理し直して解決したんじゃなくて、捨てたんだよ。柔軟さを。

**デフォルトの名無しさん** · 2018/04/09(月) 20:56:14.35

ID:2gnvm26gの主張って、エラー関係に文句言ってる奴に「別にthrow-catchでもそんなに困らなくね？」って言ってるの？

**デフォルトの名無しさん** · 2018/04/09(月) 20:56:27.27

俺には二人ともが「Javaの検査例外は失敗だった」と主張しているように読める……
なんで喧嘩してるんだろうこの人たち

**デフォルトの名無しさん** · 2018/04/09(月) 20:58:19.15

>>868
その上で例外廃止を是とするか、「ちゃんとしてれば「手に負えない例外」なんてない」って夢物語を語ってるかが違うと思う。

**デフォルトの名無しさん** · 2018/04/09(月) 21:00:24.61

なんとなく手抜きっぽいからじゃなくて、本気で手抜きだと思ってんだよなぁ。

**デフォルトの名無しさん** · 2018/04/09(月) 21:00:41.98

なんかどっちでも大して変わらんというか、
結局実装者がどれだけ丁寧に作るかどうか以上の話にならん気がする。

**デフォルトの名無しさん** · 2018/04/09(月) 21:04:04.26

まあthrows Exceptionやるような奴なら、戻り値によるエラー処理を強制したとしても
全メソッド呼び出しでErrorを盲目的に再returnするか全部握り潰してOptionalだらけにするだけだろうな

**デフォルトの名無しさん** · 2018/04/09(月) 21:06:17.30

丁寧に作ると、大域ジャンプなんかそうそう使わん。
>>872
それでも、どこか遙か上でcatchしてることを期待してthrowされるより、直上がエラーを見てる事が保証できてるほうがマシかと。
握りつぶすのは論外として。

**デフォルトの名無しさん** · 2018/04/09(月) 21:09:28.00

Javaは継承はあるがジェネリクスがない時代の遺物
タプルやEitherを使わないのもジェネリクスがなかったことが影響している

**デフォルトの名無しさん** · 2018/04/09(月) 21:11:10.68

Javaの検査例外が失敗したのは
パッと見で非検査例外と区別がつかなかったことと
try-catch文を毎回書くもがあまりにも冗長で面倒臭かったから

だからSwiftでは非検査例外の方をなくして
更にtry-catch文の改良することで検査例外を復活させてる

ID:2gnvm26gは検査例外という考え方そのものが失敗作だと思ってない？
そうじゃないよ。

**デフォルトの名無しさん** · 2018/04/09(月) 21:16:16.06

ところで検査例外って「失敗」したの？たしかにJava以降採用する言語はないけどさ。

**デフォルトの名無しさん** · 2018/04/09(月) 21:19:48.19

検査例外は多態との相性が最悪なんだよ
Java自身ですら、Lambdaで詰んでとうとう検査例外やめちゃった

**デフォルトの名無しさん** · 2018/04/09(月) 21:36:54.73

>>877
この関数は引数として渡されたクロージャと同じ種類の例外を投げますよ記法があれば良さそうに思うけどな
やることは多相型の推論と同じだろう

**デフォルトの名無しさん** · 2018/04/09(月) 21:48:04.19

あー、Javaの場合はクロージャを独立したinterfaceとして型を付けないといけないんで無理だな
すまん忘れてくれ

**デフォルトの名無しさん** · 2018/04/09(月) 21:49:57.80

例外をGenericsパラメータにして大体同じような事は出来る。
単に標準ライブラリが採用しなかっただけでは。

**デフォルトの名無しさん** · 2018/04/09(月) 22:01:05.72

動的型は平和でいいよな
検査例外やジェネリクスの無理難題を
追っぱらうため *だけ* だったとしても、それ自体、動的型を使う強力な理由になりうる

**デフォルトの名無しさん** · 2018/04/09(月) 22:29:22.04

>>872
明示的に無視するように書いてる場合は議論から除いたほうがよくない？

**デフォルトの名無しさん** · 2018/04/09(月) 23:37:00.39

Goはマスコットがきもい！！