Usman понял спасибо!

Petro123:
1. отсылку сообщений можно убрать это не проблема. Я правда не понимаю чем это вредит, ведь на сервер они не приходят. По моему разумению это просто на тот случай если кто-то вручную поработать с БД захочет - с целью дать понять в чем дело.
2. "если вся бл триггерах и бд" - нет в БД только триггеры для проверки целостности данных. Основная логика уже на клиенах. Тут в примере просто сам сервер получает сообщение - отправить его клиенту (вместо null) это уже не проблема. Мне просто как раз и не нравится именно то место где я "докапываюсь" до сообщения от триггера...
3. Спасибо что тратите на меня столько времени:)

Petro123
1. Это конечно не "рабочее" решение. То что тут кидается на вывод в консоль - чисто для меня увидеть что да мол вот я это получил. Клиенту будет отправляться вместо null например JSON объект, в котором будет лежать сообщение (или его код), но там уже разные варианты как передать и тут как раз вопросов пока вроде нет.
2. Cервер - GlassFish. Я на нем хочу получить сообщение от триггера БД (что и делаю своим корявым способом), чтобы далее донести клиенту почему то что он хочет сохранить мы сохранять нифига не будем - ради этого весь сырбор. Касательно "Ошибка из триггера будет очень редко" я не согласен - будет столько сколько попыток будет сохранить неверные данные. Да хоть бы и редко - я хочу чтобы это работало! :) Как раз интересно иметь триггер который будет делать работу и на клиенте раз оно уже делается триггером не думать снова о проверках при сохранении. Я хочу просто получать ошибки уже из базы для конкретно этих случаев (проверяемых триггерами). Вот и пытаюсь найти универсальное и правильное что-то.
возвращаясь к моему вопросу
авторто что проверять можно на клиенте перед сохранением понятно. Как раз и хотелось бы "из спортивного интереса" попробовать получить универсальное решение со стороны самой базы чтобы потом уже с увеличением количества триггеров (а оно в небольшой степени будет в любом случае) не думать ни о чем.

Petro123,

зависит от БЛ. Приведи БЛ, и мы сможем сказать как ошибку исключить малой кровью - да там все просто. Это клиент на JavaFX - данные, представленные в GUI, скажем изменяются и сохраняются (на GlassFish через rest летит сохраняемый объект). В этом месте и показывать особо нечего:( Далее триггер в одной из таблиц при сохранении в ней данных уже смотрит условия (опять же могут быть разные триггеры и условия для разных таблиц) и сохраняет все ЛИБО откатывает транзакцию (т.е. сам откат в JPA делать не надо - я посмотрел про декларативные транзакции по вашему совету, но это не суть моего вопроса). Тут все очевидно и понятно, НО при откате естественно дать клиенту знать что мол "нееее: ты мне фигню послал так что не шали тут". Я могу эту проверку сделать на клиенте еще до попытки сохранения и ничего и не пытаться сохранить это вообще не вопрос, но тогда проверки придется делать в разных местах для разных таблиц и кроме того скажем админ напрямую сможет фигню в базу загнать (коли триггер убрать вообще). Мне подумалось что коли триггер таки с этой работой справляется уже то нефиг дублировать функции а пусть он и дальше это делает, а мы от него получаем сообщения. Причем хотелось чтобы было универсально и в одном месте все ловилось от всех возможных триггеров. Вот и все. В целом сделал так что оно фурычит, но мне просто не понравилось что я поднимаю исключение в БД и ловлю его в итоге через кучу других исключений - оттого пошел на форум за советом мож что рациональнее и проще в природе имеется.

оно работает - наверх идёт райзо до перехвата вами try - таки да! Вопрос и есть в том нормально ли это что я на БД поднимаю исключение и ловлю его через кучу других.

Petro123Ещё раз!
- триггер выдал ошибку (хотите номер, хотите строку)
- вы её перехватили?
да.

Все. Понимаю что задолбал. В итоге наверное пока остановлюсь на том что есть - оно все же работает. Когда будет БЛ с JMS горю желанием попробовать все это задружить глядишь выйдет то что мне таки понравится.

Еще раз всем спасибо!