Яка користь від того, що “немає винятків із виконання”, як стверджує Elm?

Деякі мови стверджують, що вони не мають "виключень із часу виконання", як явну перевагу перед іншими мовами, які ними є.

Я плутаюся в цьому питанні.

Наскільки я знаю, і коли добре використовується, виняток з виконання - це лише інструмент:

• ви можете спілкуватися з "брудними" станами (кидаючи на несподівані дані)
• додавши стек, ви можете вказати на ланцюжок помилок
• Ви можете розрізняти безлад (наприклад, повернення порожнього значення на недійсному введенні) та небезпечне використання, яке потребує уваги розробника (наприклад, викидання виключення на недійсний вхід)
• ви можете додати детальну інформацію про свою помилку за допомогою повідомлення про виключення, надаючи додаткові корисні деталі, що допомагають налагоджувати зусилля (теоретично)

З іншого боку, мені важко налагодити програмне забезпечення, яке "проковтує" винятки. Напр

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

Отже, питання полягає в тому, у чому полягає сильна теоретична перевага того, що «немає винятків з виконання»?

Приклад

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

Жодних помилок виконання на практиці. Без нуля. Жодне невизначене не є функцією.

Винятки мають надзвичайно обмежуючу семантику. Вони повинні оброблятися саме там, де вони кинуті, або в стеку прямого виклику вгору, і програміст під час компіляції не вказує, якщо ви забудете це зробити.

Порівнюйте це з Elm, коли помилки кодуються у вигляді результатів або Maybes , які є обома значеннями . Це означає, що ви отримуєте помилку компілятора, якщо не обробляєте помилку. Ви можете зберігати їх у змінній або навіть колекції, щоб відкласти їх поводження на зручний час. Ви можете створити функцію для обробки помилок у конкретному додатку, а не повторювати дуже схожі блоки спробувати. Ви можете зв'язати їх з обчисленнями, які досягли успіху, лише якщо всі його частини досягли успіху, і їх не потрібно забивати в один блок спроб. Вас не обмежує вбудований синтаксис.

Це не що інше, як "ковтання винятків". Це робить явні умови помилок у системі типів і надає набагато більш гнучку альтернативну семантику для їх обробки.

Розглянемо наступний приклад. Ви можете вставити це на 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витягнути потрібне значення. Хоча технічно ви можете зловживати таким механізмом, сенсу немає. Оскільки ви можете відкласти рішення до тих пір, поки не знатимете гарне повідомлення за замовчуванням / помилку, яке потрібно поставити, немає причин не використовувати його.

Для того, щоб зрозуміти це твердження, спершу треба зрозуміти, що нам купує система статичного типу. По суті, те, що дає нам система статичного типу, є гарантією: якщо програма перевіряє тип програми, певний клас поведінки виконання не може виникнути.

Це звучить зловісно. Ну, перевірка типу схожа на перевірку теореми. (Насправді, згідно із ізоморфізмом Керрі-Говарда - це одне й те саме.) Одне, що дуже властиво теоремам, - це те, що, коли ти доводиш теорему, ти доводиш саме те, що говорить теорема, не більше. (Ось, наприклад, чому, коли хтось каже "Я довів цю програму правильною", ви завжди повинні запитувати "будь ласка, визначте" правильну "".) Те саме стосується систем типів. Коли ми кажемо, що "програма є безпечною для типу", ми маємо на увазі не те, що можлива помилка не може виникнути. Можна сказати лише те, що помилки, які система типу обіцяє нам запобігти, не можуть виникнути.

Отже, програми можуть мати нескінченну кількість різних режимів виконання. З них нескінченно багато корисних, але також нескінченно багато з них є "неправильними" (для різних визначень "правильність"). Система статичного типу дозволяє нам довести, що певний обмежений, фіксований набір тих нескінченно багатьох неправильних поведінки часу виконання не може відбуватися.

Різниця між системами різних типів полягає в тому, що в тому, скільки, скільки складних режимів поведінки вони можуть виявити, не виникають. Системи слабкого типу, такі як Java, можуть довести лише основні речі. Наприклад, Java може довести, що метод, який вводиться як повернення a, Stringне може повернути a List. Але, наприклад, він може НЕ довести , що метод не буде не повертатися. Це також не може довести, що метод не кине виключення. І це не може довести, що воно не поверне неправильне String  - будь- Stringякий задовольнить перевірку типу. (І, звичайно, навіть nullзадовольнить його.) Є навіть дуже прості речі , які Java не можуть довести, що саме тому у нас є винятки , наприклад ArrayStoreException, ClassCastExceptionабо все улюбленець, то NullPointerException.

Більш потужні системи типу, як Agda, можуть також довести такі речі, як "поверне суму двох аргументів" або "повертає відсортовану версію списку, переданого як аргумент".

Тепер, що дизайнери Elm мають на увазі під твердженням, що вони не мають винятків під час виконання, - це те, що система типу Elm може довести відсутність (значної частини) режимів виконання, які в інших мовах не можуть бути доведені, щоб не відбувалися, і, таким чином, це може призвести до помилкової поведінки під час виконання (що в кращому випадку означає виняток, у гіршому випадку означає збій, а в гіршому - не крах, не виняток і просто мовчазно неправильний результат).

Отже, вони не говорять, що "ми не застосовуємо винятків". Вони говорять, що "типи, що були типовими винятками у типових мовах, з якими типичні програмісти, що приїжджають до Elm, мають досвід роботи, потрапляють у систему типу". Звичайно, хтось із Ідріса, Агди, Гуру, Епіграму, Ізабел / HOL, Coq або подібних мов побачить В'яза як досить слабкого в порівнянні. Заява більш орієнтована на типових програмістів Java, C♯, C ++, Objective-C, PHP, ECMAScript, Python, Ruby, Perl….

Elm може гарантувати відсутність виключення під час виконання з тієї ж причини. C може гарантувати відсутність виключення з виконання: Мова не підтримує концепцію винятків.

Elm має спосіб сигналізації про помилки під час виконання, але ця система не є винятком, це "Результати". Функція, яка може відмовити, повертає "Результат", який містить або регулярне значення, або помилку. В'язи сильно набрані, тому це явно в системі типів. Якщо функція завжди повертає ціле число, вона має тип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's ResultтаTask ), замість того, щоб їх кидали як винятки. Це означає, що дизайнери Elm означають: багато помилок будуть виявлені під час компіляції, а не в "час запуску", і компілятор змусить вас боротися з ними, а не ігнорувати їх і сподіватися на найкраще. Зрозуміло, чому це перевага: краще, щоб програміст дізнався про проблему ще до того, як це зробить користувач.

Зауважте, що коли ви не використовуєте винятків, помилки кодуються іншими, менш дивними способами. З документації Elm :

Однією з гарантій Elm є те, що ви не побачите помилок виконання на практиці. NoRedInk використовує Elm у виробництві вже близько року, і їх досі не було! Як і всі гарантії Elm, це зводиться до принципового вибору мовного дизайну. У цьому випадку нам допомагає той факт, що Elm трактує помилки як дані. (Ви помічали, що ми багато чого робимо тут?)

Дизайнери в'язів трохи сміливі, стверджуючи, що "немає винятків із часу виконання" , хоча вони кваліфікують це як "на практиці". Вони, ймовірно, означають "менш несподівані помилки, ніж якщо ви кодували в javascript".

В'яз стверджує:

Жодних помилок виконання на практиці. Без нуля. Жодне невизначене не є функцією.

Але ви запитуєте про винятки з виконання . Є різниця.

У Elm нічого не повертає несподіваного результату. НЕ можна писати дійсну програму в Elm, яка створює помилки під час виконання. Таким чином, вам не потрібні винятки.

Отже, питання повинно бути:

Яка користь від того, що "немає помилок виконання"?

Якщо ви можете написати код, який ніколи не має помилок виконання, ваші програми ніколи не завершаться.