Elmの主張のように、「ランタイム例外なし」の利点は何ですか？

一部の言語では、「実行時例外がない」と主張している他の言語よりも明確な利点があります。

私はこの問題について混乱しています。

ランタイム例外は、私が知る限り単なるツールであり、適切に使用されている場合：

• 「ダーティ」状態を通信できます（予期しないデータでスロー）
• エラーの連鎖を指すことができるスタックを追加する
• 乱雑（無効な入力で空の値を返すなど）と開発者の注意が必要な安全でない使用（無効な入力で例外をスローするなど）を区別できます。
• エラーに詳細を追加することができます。例外メッセージを使用して、デバッグ作業に役立つさらに詳細な情報を提供できます（理論的に）

一方、例外を「飲み込む」ソフトウェアをデバッグするのは本当に難しいと感じています。例えば

try { 
  myFailingCode(); 
} catch {
  // no logs, no crashes, just a dirty state
}

質問は、「ランタイム例外なし」の強力で理論的な利点は何ですか？

例

https://guide.elm-lang.org/

実際には実行時エラーはありません。ヌルなし。未定義は関数ではありません。

例外のセマンティクスは非常に制限されています。それらは、スローされた場所、または直接の呼び出しスタックで正確に処理する必要があります。コンパイル時に、プログラマーがそれを忘れた場合は表示されません。

これを、エラーがResultsまたはMaybesとしてエンコードされるElmと比較してください。どちらも値です。つまり、エラーを処理しないと、コンパイラエラーが発生します。変数またはコレクションに保存して、処理を都合の良い時間に延期することができます。非常によく似たtry-catchブロックをあちこちで繰り返す代わりに、アプリケーション固有の方法でエラーを処理する関数を作成できます。それらをすべての部分が成功した場合にのみ成功する計算にチェーンでき、1つのtryブロックに詰め込む必要はありません。組み込みの構文による制限はありません。

これは「例外を飲み込む」ようなものではありません。型システムでエラー条件を明示し、それらを処理するためのはるかに柔軟な代替セマンティクスを提供しています。

次の例を考えてみましょう。動作を確認したい場合は、これをhttp://elm-lang.org/tryに貼り付けることができます。

import Html exposing (Html, Attribute, beginnerProgram, text, div, input)
import Html.Attributes exposing (..)
import Html.Events exposing (onInput)
import String

main =
  beginnerProgram { model = "", view = view, update = update }

-- UPDATE

type Msg = NewContent String

update (NewContent content) oldContent =
  content

getDefault = Result.withDefault "Please enter an integer" 

double = Result.map (\x -> x*2)

calculate = String.toInt >> double >> Result.map toString >> getDefault

-- VIEW

view content =
  div []
    [ input [ placeholder "Number to double", onInput NewContent, myStyle ] []
    , div [ myStyle ] [ text (calculate content) ]
    ]

myStyle =
  style
    [ ("width", "100%")
    , ("height", "40px")
    , ("padding", "10px 0")
    , ("font-size", "2em")
    , ("text-align", "center")
    ]

関数String.toInt内calculateで失敗する可能性があることに注意してください。Javaでは、これによりランタイム例外がスローされる可能性があります。ユーザー入力を読み取るため、かなりの可能性があります。代わりに、エルムはを返すことで対処するように強制しますがResult、すぐに対処する必要はないことに注意してください。私は入力を倍増し、文字列に変換し、することができ、その後に不正な入力をチェックするgetDefault機能。この場所は、エラーが発生したポイントやコールスタックの上方よりも、チェックに適しています。

コンパイラが私たちの手を強制する方法も、Javaのチェックされた例外よりもはるかにきめ細かいです。必要なResult.withDefault値を抽出するなど、非常に特殊な関数を使用する必要があります。技術的にはそのようなメカニズムを悪用する可能性がありますが、あまり意味はありません。置くべき適切なデフォルト/エラーメッセージを知るまで決定を延期できるので、それを使用しない理由はありません。

この声明を理解するためには、まず静的型システムが何を買うかを理解する必要があります。本質的には、静的型システムは、私たちを与えるもの、保証です：場合に限っプログラムタイプをチェックし、実行時の動作の特定のクラスが発生することはできません。

それは不吉に聞こえます。タイプチェッカーは定理チェッカーに似ています。（実際、カリー-ハワード-同型写像によれば、それらは同じものです。）定理について非常に独特なことの1つは、定理を証明するとき、定理が言うことを正確に証明することです。（例えば、だから、誰かが「このプログラムが正しいことを証明した」と言うとき、あなたは常に「 '正しい'を定義してください」と尋ねるべきです。同じことが型システムにも当てはまります。「プログラムはタイプセーフです」と言うとき、私たちが意味するのは、起こりうるエラーが発生しないということではありません。型システムが防止することを約束するエラーは発生しないとしか言​​えません。

そのため、プログラムにはさまざまなランタイム動作が無限に存在する可能性があります。これらのうち、無限に多くのものが有用ですが、無限に多くのものも「不正」です（「正確さ」のさまざまな定義に対して）。静的型システムを使用すると、これらの無限に多くの誤った実行時動作の特定の有限で固定されたセットが発生しないことを証明できます。

異なる型システムの違いは、基本的に、それらが発生しないことが証明できる実行時の動作の数、数、および複雑さです。Javaのような弱い型のシステムは、非常に基本的なことしか証明できません。たとえば、Javaは、を返すように入力されたメソッドがをString返せないことを証明できListます。しかし、たとえば、メソッドが戻らないことを証明することはできません。メソッドが例外をスローしないことも証明できません。そして、それが間違った ものを返さないことを証明することはできません。String どれもString型チェッカーを満足させるでしょう。（そして、もちろん、でもnull同様にそれを満足させます。）Javaは証明できないことも、非常にシンプルなものがありますが、私たちのような例外が持っている理由であるArrayStoreException、ClassCastExceptionまたはみんなの大好きな、NullPointerException。

Agdaのようなより強力な型システムは、「2つの引数の合計を返す」または「引数として渡されたリストのソートされたバージョンを返す」などのことも証明できます。

さて、エルムの設計者がランタイム例外がないというステートメントによって意味するのは、エルムの型システムは、他の言語では発生しないことが証明できないため、その結果、実行時の誤った動作（最良の場合は例外を意味し、最悪の場合はクラッシュを意味し、最悪の場合はクラッシュなし、例外なし、静かに間違った結果を意味します）。

そのため、彼らは「例外を実装しない」と言っているわけではありません。彼らは「エルムに来る典型的なプログラマーが経験するであろう典型的な言語の実行時例外となるものは、型システムに捕らえられる」と言っています。もちろん、イドリス、アグダ、グル、エピグラム、イザベル/ HOL、Coq、または同様の言語から来た人は、エルムを比較するとかなり弱いと見なします。このステートメントは、典型的なJava、C♯、C ++、Objective-C、PHP、ECMAScript、Python、Ruby、Perlなどのプログラマーを対象としています。

Elmは同じ理由でランタイム例外がないことを保証できます。Cはランタイム例外がないことを保証できます。言語は例外の概念をサポートしていません。

Elmには実行時にエラー状態を通知する方法がありますが、このシステムは例外ではなく、「結果」です。失敗する可能性のある関数は、通常の値またはエラーを含む「結果」​​を返します。Elmsは強く型付けされているため、これは型システムで明示されています。関数が常に整数を返す場合、そのタイプはになりIntます。ただし、整数を返すか失敗した場合、戻り値の型はResult Error Intです。（文字列はエラーメッセージです。）これにより、呼び出しサイトで両方のケースを明示的に処理する必要があります。

ここで紹介の例は、（ビットの簡略化）：

view : String -> String 
view userInputAge =
  case String.toInt userInputAge of
    Err msg ->
        text "Not a valid number!"

    Ok age ->
        text "OK!"

toInt入力が解析可能でない場合、関数は失敗する可能性があるため、戻り値の型はResult String intです。実際の整数値を取得するには、パターンマッチングを介して「アンパック」する必要があり、これにより両方のケースを処理する必要があります。

結果と例外は基本的に同じことを行いますが、重要な違いは「デフォルト」です。デフォルトでは、例外はバブルアップしてプログラムを終了します。例外を処理するには、例外を明示的にキャッチする必要があります。結果は別の方法です-デフォルトでそれらを処理することを余儀なくされるので、プログラムを終了させたい場合は、それらを一番上まで明示的に渡す必要があります。この動作がより堅牢なコードにどのようにつながるかは簡単にわかります。

まず、「飲み込む」例外の例は一般にひどい習慣であり、実行時例外がないこととはまったく関係がないことに注意してください。考えてみると、実行時エラーがありましたが、それを非表示にして何もしないことにしました。これにより、理解しにくいバグがしばしば発生します。

この質問はさまざまな方法で解釈できますが、コメントでElmについて言及したので、コンテキストはより明確です。

Elmは、とりわけ静的に型付けされたプログラミング言語です。この種の型システムの利点の1つは、プログラムが実際に使用される前に、多くのクラスのエラー（すべてではないが）がコンパイラーによってキャッチされることです。いくつかの種類のエラーは、例外としてスローされる代わりに、型（Elm ResultやTask）などでエンコードできます。これがElmの設計者が意味することです。多くのエラーは「実行時」ではなくコンパイル時にキャッチされ、コンパイラはそれらを無視して最善を期待するのではなく、それらの処理を強制します。これが利点である理由は明らかです。ユーザーが気付く前にプログラマーが問題に気付く方が良いです。

例外を使用しない場合、エラーは他の驚くほど簡単な方法でエンコードされます。Elmのドキュメントから：

Elmの保証の1つは、実際には実行時エラーが発生しないことです。NoRedInkは、生産でElmを約1年間使用していますが、まだ持っていません！Elmのすべての保証と同様に、これは基本的な言語設計の選択に帰着します。この場合、Elmはエラーをデータとして扱うという事実に助けられます。（ここでデータをたくさん作成していることに気づきましたか？）

エルムのデザイナーは、「実行時の例外なし」を主張するのに少し大胆です。それらが意味する可能性が高いのは、「javascriptでコーディングしている場合よりも予期しないエラーが少ない」ことです。

エルムの主張：

実際には実行時エラーはありません。ヌルなし。未定義は関数ではありません。

しかし、実行時例外について尋ねます。違いがあります。

Elmでは、予期しない結果を返すものはありません。実行時エラーを生成する有効なプログラムをElmで作成することはできません。したがって、例外は必要ありません。

したがって、質問は次のようになります。

「実行時エラーなし」の利点は何ですか？

実行時エラーが発生しないコードを作成できれば、プログラムはクラッシュしません。