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 эта штука включена, между прочим.