Scalaでの未チェックの例外の決定

Javaプログラマーとして、私は未確認の例外に対して常に批判的でした。ほとんどのプログラマーは、後でトラブルを引き起こす場合にのみ、コーディングの容易さへの途中でそれを使用します。また、チェックされた例外を持つプログラム（乱雑ですが）は、チェックされていない対応するプログラムと比較して非常に堅牢です。

驚くべきことに、ScalaにはChecked Exceptionsと呼ばれるものはありません。Scalaでは、チェックされているJavaとチェックされていないJavaはすべてチェックされていません。

この決定の背後にある動機は何ですか？私にとっては、外部コードを使用するときにさまざまな問題が発生します。また、偶然ドキュメントの質が悪い場合は、KILLになります。

チェックされた例外は、ほとんどが失敗と見なされます。Javaがそれらを採用した後に作成された言語はないことに注意してください。参照http://www.artima.com/intv/handcuffs2.html、http://googletesting.blogspot.ru/2009/09/checked-exceptions-i-love-you-but-you.html、のhttp：/ /www.mindview.net/Etc/Discussions/CheckedExceptionsなど

特に、それらは合成できません（に戻すことを除くthrows Exception）。

Scalaでは、より良いオプションがあります：Option[T]、などの戻り値に代数型をEither[Exception, T]使用して、ユーザーに特定のケースを処理させたいときに独自の型（たとえば

def foo: Int // throws FileNotFoundException, IllegalStateException

あなたが持っている

sealed trait FooResult
case class Success(value: Int) extends FooResult
case class FileNotFound(file: File) extends FooResult
case object IllegalState extends FooResult

def foo: FooResult

消費者はすべての結果を処理する必要があります）

例外をスローする外部コードを処理するには、scala.util.control.exceptionまたはscala.util.Try（Scala 2.10以降）が必要です。

Javaでチェックされた例外は、それほど悪いことではありません。もちろん、ADTはScalaのより良いオプションかもしれませんが、Javaでは、チェック例外が代わりに使用され、整頓されたコード引数は、ブログが何度繰り返されても無意味です。基本的には、システムで発生する可能性のある深刻で修復可能な状態を喜んで無視する必要があると言われています。ネジ式システム、きれいなコードにより、システムが自動的に堅牢になります。このような推論は、なぜ多くのJavaコーダーが自発的にコードをXMLに移動するのかを説明します（Spring、Mavenなど。ここでかなりの部分を見逃しています）。

http://www.scala-lang.org/old/node/8787.htmlの下のM. Oderskyによって与えられたScalaでチェック例外が欠如している理由は、驚くほど異なっており、理にかなっています。

チェック例外の問題は、リストのmapメソッドによって最もよく実証されます。

def map[B](f: A => B): List[B]

@throwsでマップに注釈を付ける方法は？mapが@throwsアノテーション自体を取得しない場合、おそらく@throwsを持つ関数を渡すことはできません。これにより、マップの使用方法に関する面倒な制限と区別が導入されます。関数の引数がスローするすべての例外をマップがスローすることをなんとか述べることができれば、事態は改善されるでしょう。これを表現できるエフェクトシステムはいくつかありますが、これまでのところ、私が見た表記はすべて重すぎます。

Lukas Rytzは、マップのタイプやその他の一般的な機能を簡潔かつ正確に表現するために使用できる軽量のエフェクトシステムに関する研究を行っています。それは研究であるため、現時点では、どの程度成功するか、どれだけScalaに投入できるかは不明です。理想的には、ある時点でオプションの型システムとして追加できるようになります。しかし、具体的な予測をするのは時期尚早です。

乾杯

確かではありませんが、Java 8ラムダも未チェックの例外に制限されていると思います。JDK 8（java.util.function.*）のほとんどの（すべて？）新しい機能インターフェイスのメソッドは、未チェックの例外も宣言しません。

効率を上げたい場合は、あきらめなければなりません。precision / control <-そのためのより良い言葉が必要です。

Scalaは、抽象化の範囲内で一番上に位置しています。Scalaの目標の1つが迷惑な定型コードを取り除くことである場合、注目すべき明らかな場所はJavaの例外処理です。Javaで高速コードを記述したい場合は、チェック例外がヒットmain()して実質的にチェック解除されるまで、チェック例外をスローし続けるだけです。

あなたが求めていることを正確に把握しているかどうかはわかりませんが、これが私の意見で最も明白な理由です。

さて、私は少し調べて、誰かがチェック例外の悲劇について書いています。