Конец Checked Exceptions

[yakov_sirotkin]

Java сыграла огромную роль в обучении миллионов программистов обработке ошибок, надо отдать ей должное. И идея была красивая, что каждый метод будет честно признаваться, какой подлянки от него ждать. Многие сразу говорили, что будет catch (Exception e) {}, но это явная патология, которая автоматически обнаруживается любым анализатором кода

Comments

[asolntsev]

Да что там Kotlin, их уже в C# не было в принципе.

[ext_650079]

NPE - одна из главных проблем в Java.

[jakobz]

Насчет NPE. Главный по C# говорил где-то что жалеет что они сделали всем ссылочным типам возможность иметь значение null по-умолчанию. Что надо было делать как с value-типами во втором шарпе - по умолчанию null нельзя, но можно заюзать Nullable<> и спец. синтаксис для него (string? myString).

Впрочем, в C# либо пишут как-то иначе, либо еще что-то, но NPE в .net-приложениях не так уж и часто вылетают.

[yakov_sirotkin]

Просто чем больше разработчиков, тем больше NPE:)

[jakobz]

Думаю обработка ошибок ортогональна ООП. В том же Хаскеле другие средства для обработки ошибок, но суть - та же.

Это все вопрос правильной системы типов и удобства ее использования (вывода типов, в частности).

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

Но нет ведь - делают везде корявую ad-hoc реализацию, только чтобы индусы не испытывали когнитивный диссонанс.

[jakobz]

Я не против try-catch. Но я и за то, чтобы типы функций задавались полностью. Не только что там в хорошем раскладе бывает, а еще и что может вылететь, и что может прилететь (в случае передачи функций как параметра).

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

То, что толстолобые ООП-шники не осилили, не говорит вообще ни о чем.

[_navi_]

Отсутствие checked exceptions в Kotlin - это, по-моему, controversial decision. В том, что тебя напрягает UEE виноваты не checked exceptions, а корявый API design.

Я вот сейчас сильно страдаю от того, что у меня нету checked exceptions в C++, а прикрутить их самостоятельно (написанием проверяющего тула) туда очень сложно.

[yakov_sirotkin]

Думаю, у JetBrains не было никаких сомнений, я как-то на конференции спросил Макса Шафирова, какие в Котлине exceptions и он ответил мгновенно и не задумываясь.

Понятно, что ты лично страдаешь, но я согласен с цитатой из Эккеля:

Examination of small programs leads to the conclusion that requiring exception specifications could both enhance developer productivity and enhance code quality, but experience with large software projects suggests a different result - decreased productivity and little or no increase in code quality.

[_navi_]

Думаю, у JetBrains не было никаких сомнений, я как-то на конференции спросил Макса Шафирова, какие в Котлине exceptions и он ответил мгновенно и не задумываясь.
По-моему, это два совершенно несвязанных утверждения. То что тебе ответили мгновенно и незадумываясь - это потому что вопрос много обсуждался и решение было чётко принято. Я кажется общался по поводу checked exceptions (и каких-то ещё неровностей в языке) с Андреем Бреславом когда он с Димой Жемеровым объявил язык на JVM Language Summit - они знали, что это решение не всем понравится.

Отсылка к авторитету, к сожалению, тоже плохо работает в данном случае: я хочу exception specification как раз на большом проекте, потому что иначе у меня нету никакой практической возможности гарантировать качество продукта и то, что данные пользователя не будут повреждены.

[yakov_sirotkin]

Я цитирую авторитета только из-за того, что его слова полностью согласуются с моим собственным опытом. И, если вспомнить те продукты, с которыми я имел дело, то никакими гарантиями качества там и не пахло.