Re[4]: Result objects - все-таки победили Exceptions?
От: Shmj Ниоткуда  
Дата: 07.01.25 10:01
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Да много проблем. Их никто не использует, думаю, это достаточный индикатор того, что что-то с ними не так. У тебя методы превращаются в длиннющие throws из десятков исклюючений. Ты добавляешь в одну реализацию работу с XML и интерфейс должен кидать это исключение, все клиенты сломаны, теперь это XML исключение должно бросаться изо всех клиентов этого интерфейса.


Не все поняли как правильно пользоваться. Исключение — это часть конракта. Если контракт не изменялся — то новое исключение не добавляете, просто пишите в inner того исключения, которое является частью контракта. Выше приводили пример с сериализацией — SerializationException — а внутри уже inner. Сериализатор перехватывает только наследников StreamException.

vsb>Или на каждый класс надо создавать отдельное исключение, а то и на каждый метод, заворачивающий вложенное исключение. И весь смысл этой типизации теряется кроме тонн лишней писанины.


Там где не нужна акцентуация — просто оборачиваете в RuntimeException — не проверяемое.

vsb>Я не отрицаю некоторого смысла во всей этой идее проверяемых исключений, но конкретно в Java реализация фатально плохая. И я не уверен, что знаю, как сделать лучше.


Просто не поняли идею.

vsb>Думаю, сегодня уже никто не будет отрицать, что и языки с динамической типизацией и языки со статической типизацией имеют свои плюсы и минусы. При этом тем же Haskell-ем, который можно считать эдакой кульминацией статической типизации, мало кто пользуется, не в последнюю очередь из-за сложности. Больше пользуются языками, которые в основном статически типизированы, но в отдельных местах не гнушаются динамической типизации. Нет ничего криминального в том, чтобы передать значение, как Object и потом проверить его через instanceof. Ну не проверит компилятор это место, ну и ладно, переживём.


Возможно дело не в сложности — а в непривычности. И в том что он сырой еще, над ним мало работали. Возможно лет через 50 человечество до него дорастет.

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


Просто люди не проработали в голове концепцию и как бы боятся исключений. Привыкли терять контроль над кодом. У меня каждый метод КАЖДЫЙ — я 100% знаю не только параметры, но и все возможные исключения, которые он может выбросить. Т.е. 100% контроль кода. А люди привыкли к исключениям относиться как к магии. Как бы какая-то неприятность, которой быть не должно.
=сначала спроси у GPT=
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.