rdmДопусти есть некий метод на уровне сервиса, как лучше возвращать результаты его работы?
Сейчас я использую два подхода, они мне оба не нравятся)

1. Если метод выполнился без исключений - возвращаются результаты работы, иначе исключение.


2. Возвращается объект состоящий из самих результатов работы и enum'а.
Например, (myENUM.OK, resultObj), (myENUM.USER_UNDEFINE, null), (myENUM.SERVICE_NOT_AVAILABLE, null).

Как правильно делать? )rdmСоответственно в контроллере делаю switch по enum, либо catch для исключений.rdmСоответственно в контроллере делаю switch по enum, либо catch для исключений.Просто Вы не умеете готовить этих "кошек".
Обычное дело. Если на каждый чих создавать отдельный класс-исключение ерунда получится.

rdmWGA, по подробнее можно? )Я невеликий спец и вряд ли хорошо сформулирую. Но попробую. На правах пятницы )
1) Коды возврата - это плохо. Проверено временем. Enum - практически то же самое, кстати. Если у Вас длинный стектрейс, то это "добро" еще и передавать надо по цепочке. Вспомните, для чего механизм исключений был вообще придуман.

2) Разберитесь в своем бардаке исключений. Если их слишком много - что-то недоработано, где-то они использовались слишком механистически, по шаблону. Checked exceptions - вообще дело тонкое. В смысле супротив RuntimeException и иже с ним. Понимание этого механизма выедает мозг, но стОит того.

Пример.
Одна и та же исключительная ситуация может вылиться как в checked-, так и unchecked-exception. От чего это зависит? По большей части от того, как ты оцениваешь фатальность исключительной ситуации, т.е. если "шеф! все пропало!", то runtime, а если "тут непонятки возникли, может чо еще можно сделать" - тогда checked. Вообще много по этому поводу написано. Вряд ли я смогу лучше )

3) Найдите общность в реакции системы на различные классы исключений. Проще говоря, сведите однотипную обработку исключений в одну точку.

Пример.
Если у вас runtime-исключение, то можно написать один servlet filter, который будет отдавать пользователю ответ "извините, у нас случилась непредвиденная хрень, мы работаем над над ней". Если checked, то типичный сценарий, что в контроллере ты должен принять решение, что с этим делать.

4) Продумайте иерархию классов, чтобы не декларить их все в методах.


-------------------------------------

В общем как-то так.

rdmДопустим есть выдуманный метод )

[src java]
public ... myMethod(int a, int b) {

//какие-нибудь ограничения накладываемые на a и b, которые нельзя проверить через Bean Validate
//
Вообще говоря можно .

Можете взять модель исключений в Bean Validation, если не хотите закладываться на provider-специфичные особенности (см. JSR-303, Appendix C). Но в JavaEE 7 эта штука включена, между прочим.

rdmЕсли вы говорите о Error или RuntimeException спору нет, а если проверяемое исключение?
Например пользователь исчерпал лимит чего-нибудь, лучше выдать сообщения, чем 500.Так я ж и говорю - Вы не умеете готовить исключения )
Зачем же сразу 500-я??? Допустим у Вас контроллер обычный сервлет. В него заинжектили ссылку на EJB. Дергаете метод, который выкидывает MyValidationException. Ловите исключение в контроллере, принимаете решение что делать, например, перенаправляете на страницу, на которой вежливо объясняете пользователю, что он там исчерпал.

Поймите, что наружу все равно надо передать инфу об исключительной ситуации. Тем или иным способом. Исключения просто поудобнее.
1) Обходите ограничение на единственный возвращаемый объект.
2) Явно декларируете возможную исключительную ситуацию, обязывая ее обработать. Не редкость, что бэк-энд и фронт разрабатывают разные люди.
3) Получаете возможно "перескочить" наверх по цепочке вызовов без необходимости возвращать enum'ы или другие объекты.

Petro123WGAПоймите, что наружу все равно надо передать инфу об исключительной ситуации.
ну, если просто сайт. Публичный сайт. То юзверю не выводится. В целях безопасности.Конечно, я упрощаю.
rdmСейчас понимание приходит) А еще мне очень понравился MethodValidate HV, везде понатыкаю его.Не надо "втыкать" повсюду ) Достаточно создать один класс-интерцептор (если используете EJB) или один аспект, если Spring. Method Validation и задумывалось с таким расчетом.
Проверяем описание класса и если задекларирован специальный класс-исключение (или его потомок), то выбрасываем такое исключение. Если же нет - выбрасываем RuntimeException, у которого cause = заданному исключению. Надеюсь понятно объяснил.

rdmWGA, я понял из прочитанного(для Spring), что вещается интерцептор, которые проверяет сначала параметры вызова, затем выполняет тело метода и потом проверяет результат работы метода. Если в одна из двух проверок "проваливается" генерируется исключение(для меня не понятно почему оно не проверяемое) со списком значений, в которых собственно и содержится информация о причинах возникновения.В Spring не юзал, не скажу. Непроверяемое - потому что в общем случае интерцептор не может выбрасывать исключение, которое не объявлено обернутым методом. Иначе получишь не совсем то, что ожидал )

rdmЯ вижу минус в том, что IDE не заставит их обработать, т.е. вполне можно забыть обернуть вызов метода в блок try catch )Можно подумать оно помешает не обрабатывать их в других случаях...

Из примеров когда заставит не просто среда, а компилятор - декораторы в EJB (точнее в CDI). Там рулит type-safe...

rdmWGAпропущено...
Можно подумать оно помешает не обрабатывать их в других случаях...

Из примеров когда заставит не просто среда, а компилятор - декораторы в EJB (точнее в CDI). Там рулит type-safe...
Подробнее можно? ) Можно .