Как стать автором
Обновить

Комментарии 17

Теоретически, все перечисленные «кандидаты» представляют собой одно и то же. Разница вариантов, не использующих исключения, представляет собой «постоянный множитель». Отличие вариантов, использующих исключения, в том, что в исключении заполняется стек вызовов, и на это тратится время. (но, с другой стороны, стеки полезны при поиске ошибок). Так что для полноты картины надо в соревнование добавить вариант с исключениями без стека (в java для этого надо унаследоваться от Exception и перекрыть fillInStackTrace(), а в Scala, насколько я помню, такой наследник есть в стандартной библиотеке).
>Так что для полноты картины надо в соревнование добавить вариант с исключениями без стека

Включить можно, но для практики это скорее всего ничего не даст. Вы можете свое исключение таким создать, но попробуйте для чужих проделать эту операцию. То есть, если вы ловите условный IOException, то стек за вас уже заполнили, и какое-то время потрачено.

Это даст реальное сравнение в данном контексте, а так тут сравнивается две группы вариантов: со эксепшенами (с получением стека) и без них. Вторые конечно стали победителями.
А если в первой группе не вычитывать стэк, то победитель станет уже и не так очевиден.


Если же рассматривать условный вариант с IOException, то тут тоже не будет профита относительно второго варианта, так как эксепшн у вас уже всё равно есть.

>эксепшн у вас уже всё равно есть.
Ну да. Собственно, я тут про то, что если вы где-то внутри ловите чужие исключения, то вы фактически всегда имеете стек. И как вы дальше не выкручивайтесь, все равно это уже будет медленно, ибо поздно пить боржоми.

А померять конечно стоит.

Конечно качественно мы имеем две категории — исключения и АТД, но поскольку таких типов в Scala несколько интересно не только сравнить эти две категории, но и несколько разных подходов к обработке ошибок с помощью АТД.
Исключения без трейса это интересный кандидат, пожалуй добавлю его к сравнению.

>Scala, haskell и другие функциональные языки

Это вы про Java 8? :)

В Java к сожалению ADT почти не используются и даже стандартный Optional не рекомендуется использовать в интерфейсах и передавать между методами.

Я не знаю, с чего вы такое взяли, скажу только, что возможностей например vavr.io (javaslang), или других библиотек, где реализованы Either или Try — их вполне достаточно, чтобы в Java 8 пользоваться ровно тем же вариантом, который тут предлагается для скалы.

Я это лично делал уже в трех проектах.

Я не говорю про библиотеки, с ними можно все, стандартная библиотека ни в Java 8 ни в Java 11 не поощряет такой подход

> с ними можно все
Ну, не совсем. До Java 8 как раз кое-что было нельзя (практически совсем). Лямбды дали возможность сделать Try.of(()->«вычисления»), и вычисления эти стали внезапно ленивыми. Потому что это всего-лишь параметр для метода, и раньше он вычислялся до вызова — теперь тоже, но теперь это функция.

И это пожалуй то самое изменение, которое и делает все это в целом возможным и осмысленным. Во всяком случае до Java 8 я таких библиотек припомнить не могу (хотя Either были уже лет 10 назад, сразу с выходом Java 5).

Ну, теоретически такое было возможно и до 8 версии, просто выглядело более громоздко, но та же IDEA это скрывала

что-то я не вижу тут нигде 3-ёх волшебных букв jmh — а это значит что результаты можно считать близкими к рандомным и непригодными для каких-либо выводов

Не jmh единым

final case class Failure[+T](exception: Throwable) extends Try[T] {...}


Т.е. при использовании Try исключение равно создаётся, соответственно, и стек-трейс будет заполнять. Нужен ещё один вариант: исключение без заполнения стек-трейса вместе с Try. :)

Подпишите, пожалуйста оси. Очень сложно понять что на графиках.

Поправлю, по оси x доля ошибок в датасете, по оси у — время выполнения (в абстрактных попугаях, так как зависит от окружения)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории