Здравствуйте, Donz, Вы писали:
D>Тогда таким образом можно трактовать любое исключение. Ну не вовремя ява-машина запустилась: сервер сгорел или у пользователя настроение плохое D>IOException — даже само название класса исключения говорит о том, что произошла ошибка ввода/вывода, то есть надо смотреть в сторону работы с потоками. D>IllegalStateException — ява-машина не готова запустить какой-либо метод или выполнить операцию из-за состояния самой ява-машины, а не внешнего состояния, как это уже сказал Blazkowicz
Да, ок, согласен, что IOException точнее указывает на то, что произошла ошибка i/o, чем ISE.
Я ж человек ленивый, предпочитаю использовать стандартное и готовое. Но! Есть вариант, поражающий своей точностью — заводим свой unchecked CantWriteToFileException, и кидаем его в этом случае. IOException просто отдыжает
Здравствуйте, bolshik, Вы писали:
B>Здравствуйте, aka50, Вы писали:
A>>В случае с Runnable видно: выше никого нет (разве что Thread.UncaughtExceptionHandler), а в случае с Callable интерфейс явно говорит, что ошибка будет обработана (хотя бы в виде ExecutionExeception).
B>Имхо то, что у call стоит throws Exception значит не то, что 'ошибка будет обработана', а то, что код, работающий с этим интерфейсом, должен писать обработчик Exception.
Что в общем-то одно и то же — принуждение к обработке. try { } catch( Exception ignore) {} — это тоже своего рода обработка.
A>>Я, если честно, не в восторге от подхода spring-а к тотальному отказу от checked. Но с другой стороны spring обычно используется для объединения компонент. B>Ну, скажем, DataAccessException используется для объединения с субд.
Это и есть иллюстрация подхода "it depends" и правила "unchecked — это критическое событие". Т.к. доступ к бд — это отдельный модуль (который еще может помимо прочего еще и прозрачно ексепшины преобразовывать). При этом DataAccessException вполне сочетается с критическим событием и как минимум сессию в web приложении полюбому грохать... При этом при ошибке sql no records found, лучше наверное возвращать пустой список или null, чем швыряться unchecked. В случае с writeFile решение о том, фатально это или нет должен принять внешний код, и чтобы не было у него сурпризов в виде uchecked их лучше сделать checked. B>По такой логике джавадок вообще вредная вещь, потому что порождает проблемы с актуальностью?
Да, т.к. это примерно то же самое, что сделать все методы Object, а уже внутри проверять. Реальные типы описывать в javadoc. Зато пользователю будет удобно можно пихать в метод что угодно...
К стати, как вариант можно делать два метода, writeAndForget() и writeData() throws IOException
Здравствуйте, aka50, Вы писали:
A>Да, т.к. это примерно то же самое, что сделать все методы Object, а уже внутри проверять. Реальные типы описывать в javadoc. Зато пользователю будет удобно можно пихать в метод что угодно...
Имел ввиду параметры методов типа doIt(Object param1, Object param2)
Здравствуйте, bolshik, Вы писали:
B>Я ж человек ленивый, предпочитаю использовать стандартное и готовое. Но! Есть вариант, поражающий своей точностью — заводим свой unchecked CantWriteToFileException, и кидаем его в этом случае. IOException просто отдыжает
Ну в общем, я предпочитаю кинутые VM исключения сохранять приблизительно такими, какие они есть, а не создавать исключение другого класса.
К тому же, ты сам сказал выше:
Все модули общаются через строго определенный надор интерфейсов, в которых зафиксированы эксепшны, которые могут методы и указано, в каких случаях это происходит, т.е. мы можем понять, когда стоит их ловить и обрабатывать...
checked исключение в интерфейсе можно зафиксировать в отличие от unchecked. Уповать на хороший жавадок и то, что пользователь твоей библиотеки будет вдумчиво его читать, всё же не стоит.
Поскольку имхо мы уже чутка зацикливаемся, официально заявляю, что твоя точка зрения мне понятна
Не могу с уверенностью сказать, что понятно объяснил свою
Подход к использованию checked/unchecked, при котором checked не используются, а unchecked корректно описываются в контракте метода, мне нравится больше.
Засим предлагаю завершить
Здравствуйте, Donz, Вы писали:
D>Ну в общем, я предпочитаю кинутые VM исключения сохранять приблизительно такими, какие они есть, а не создавать исключение другого класса.
Это здорово, вот если бы только исключения VM были unchecked...
D>К тому же, ты сам сказал выше:
D>
D>Все модули общаются через строго определенный надор интерфейсов, в которых зафиксированы эксепшны, которые могут методы и указано, в каких случаях это происходит, т.е. мы можем понять, когда стоит их ловить и обрабатывать...
D>checked исключение в интерфейсе можно зафиксировать в отличие от unchecked.
Что значит '... в отличие от unchecked'? Кто-то запещает объявить в интерфейсе метод с деклацацией unchecked эксепшна во throws?
D>Уповать на хороший жавадок и то, что пользователь твоей библиотеки будет вдумчиво его читать, всё же не стоит.
Равно как и на то, что пользователь не будет делать catch (Exception ignore) {}
Здравствуйте, bolshik, Вы писали:
B>Что значит '... в отличие от unchecked'? Кто-то запещает объявить в интерфейсе метод с деклацацией unchecked эксепшна во throws?
Ок, можно, но всё равно смысла нет Ни разу, кстати, не видел, чтобы кто-то объявлял unchecked исключения в интерфейсе
D>>Уповать на хороший жавадок и то, что пользователь твоей библиотеки будет вдумчиво его читать, всё же не стоит.
B>Равно как и на то, что пользователь не будет делать catch (Exception ignore) {}
В этом случае программист точно сознательно забьёт на обработку. А джавадок он может невнимательно прочитать и про объявление исключения в интерфейсе забыть.
В общем, каждый остался при своём мнении Предлагаю дискуссию закончить.
С пятницей
Здравствуйте, ddocker, Вы писали:
D>аяй-яй, что же вы так тестовые задания всем интернетом решаете: http://company.yandex.ru/inside/job/dev_bugtracker.xml
Интересно, что скажут по этому обсуждению экзаменаторы из Яндекса
