Перевірені винятки на Java - це не так вже й погано. Звичайно, ADT можуть бути кращим варіантом для Scala, але в Java перевірені винятки мають своє місце, і аргументований код є просто незрозумілим безглуздим незалежно від того, скільки блогів це повторили. Це в основному говорить про те, що вам слід із задоволенням ігнорувати важкі та, можливо, відновлювані умови, які можуть статися у вашій системі, оскільки система гвинтового типу, гарний код, робить вашу систему надійною автоматично. Таке міркування також пояснює , чому так багато Java кодеров добровільно перемістити свій код в XMLs (Spring, Maven і т.д. Я сумую досить частина , хоча тут).
Причина відсутності перевірених винятків у Scala, наведена М. Одерським нижче http://www.scala-lang.org/old/node/8787.html, не дивно відрізняється і має сенс.
Проблема з перевіреними винятками найкраще демонструється методом карт у списках:
def map[B](f: A => B): List[B]
Як коментувати карту за допомогою @throw? Якщо карта не отримує анотацію @throw сама по собі, імовірно, ви не можете передати їй жодну функцію, яка має @throw. Це ввело б громіздкі обмеження та відмінність способів використання карти. Все було б краще, якби ми якось констатували, що карта викидає всі винятки, які кидає її аргумент функції. Існують деякі системи ефектів, які можуть це виразити, але поки що кожне позначення, яке я бачив, занадто важке.
Лукас Ріц проводить деякі дослідження систем легкого впливу, які можна було б використовувати для стислого і точного вираження типу карти та інших загальних функцій. Це дослідження, тому наразі незрозуміло, до якої міри ми досягнемо успіху і скільки цього можна вкласти в Scala. В ідеалі ми зможемо додати його в якийсь момент у вигляді додаткової системи типу. Але робити конкретні прогнози набагато рано.
Ура
Не впевнений, але я думаю, що лямбди Java 8 також обмежені неперевіреними винятками.Методи у більшості (усіх?) Нових функціональних інтерфейсів у JDK 8 ( java.util.function.*
) не оголошують ні перевірених винятків, ні.