ΛO
Ну потому что иначе ты про сути делаешь свои исключения
Size: a a a
2020 March 19
ΛO
И либо пишешь много бойлерплейта, либо начинаешь городить свою библиотеку для монад, ещё больше в это всё влезаешь, потом понимаешь, что где-то не очень хорошо продумал архитектуру, но твоя проблема уже расползлась по всему коду
ΛO
Котлин довольно явно все это рекомендует не делать
AL
Ну с такими ошибками точно процесс такой:
Проверьте, что вы на свежем Котлине.
Пишите ишью или лайкните существующие, если найдёте.
Проверьте, что вы на свежем Котлине.
Пишите ишью или лайкните существующие, если найдёте.
AN
В первый раз такое вижу не в идее...
М
Если нужна обработка исключительных ситуаций, то не лучше
ошибка == исключительная ситуация? Если для JVM это исключение, которое не может быть обработано, то для нашей программы оно должно быть предусмотрено и обработано как вариант развития событий.
ΛO
ошибка == исключительная ситуация? Если для JVM это исключение, которое не может быть обработано, то для нашей программы оно должно быть предусмотрено и обработано как вариант развития событий.
Не понял, что вы хотите мне сказать
М
Не понял, что вы хотите мне сказать
"Если нужна обработка исключительных ситуаций, то не лучше" Вы обработали все исключительные ситуации и имеете текущее состояние, данных нет, они недоступны итд, зачем бросать далее собственный эксепшен если можно передать контейнер с нужными типами? Для нас это уже не исключительная ситуация, она предусмотрена и обработана.
ΛO
"Если нужна обработка исключительных ситуаций, то не лучше" Вы обработали все исключительные ситуации и имеете текущее состояние, данных нет, они недоступны итд, зачем бросать далее собственный эксепшен если можно передать контейнер с нужными типами? Для нас это уже не исключительная ситуация, она предусмотрена и обработана.
Если обработали, то не надо ничего бросать, если частично обработали, но нужно пробросить выше, значит ещё не до конца обработали
Или я как-то неправильно понял это жонглирование терминами
Или я как-то неправильно понял это жонглирование терминами
ΛO
Нет чёткого определения, по которому можно сказать, реализовывать ли те или иные ошибки через исключения
VP
Потому что исключительность ситуации - вещь расплывчатая
М
Если обработали, то не надо ничего бросать, если частично обработали, но нужно пробросить выше, значит ещё не до конца обработали
Или я как-то неправильно понял это жонглирование терминами
Или я как-то неправильно понял это жонглирование терминами
Имелось ввиду именно создание своих эксепшенов именно для "пробрасывания выше" именно в качестве "исключительных ситуаций"🤗
ΛO
В общем, в моей практике почти все юзкейсы Either это обработка ошибок в таком же смысле, в котором ошибки обрабатывают исключениями. Если нужно их обработать в каком-то другом смысле, что бывает довольно редко, то часто имеет смысл написать свой тип данных с более конкретной семантикой.
NY
Ребят, а сравнение чисел с плавающей запятой в котлине чем-то отличается от java? Или equals отрабатывает аналогично джаве и следует так же прибегать к BigDecimal?
VP
Ребят, а сравнение чисел с плавающей запятой в котлине чем-то отличается от java? Или equals отрабатывает аналогично джаве и следует так же прибегать к BigDecimal?
В целом всё так же, но может быть разница там, где поведение сравнений отличается от equals и compareTo
NY
А можно пример для пободного исключения?
VP
А можно пример для пободного исключения?
Double.NaN == Double.NaN -> false
Double.NaN as Any == Double.NaN -> trueVP
В общем, сахарок может сбить с толку, надо помнить, что под капотом та же джава
АО
Почитал обсуждение выше и вспомнил, что очень (со всей силушки прям) хочется sealed interface -.-
M
Как можно это на kotlin DSL перенести?
jvmJar {
dependsOn(jsBrowserProductionWebpack)
from(new File(jsBrowserProductionWebpack.entry.name, jsBrowserProductionWebpack.outputPath))
}