Здравствуйте, Sinclair, Вы писали:

В>>Ну и нафига мне на клиенте имя таблицы? И вообще, зачем на клиенте знать что-то о какой-то там базе данных?
S>Ну а нафига тебе на клиенте та строка, которую я привел? А она достаточно типична.

А этой строки не должно быть на клиенте. В крайнем случае на клиенте будет что-то типа: "неизвестное исключение" и кнопка "дополнительно" с таким текстом, который отправляется разработчику. Так вот, и речь как раз о том, что отловить такой эксепшин на уровне СУБД (в хранимой процедуре) и превратить его в "человеческий вид" намного проще, чем формировать определенный тип исключения и потом на клиенте с ним чего-то делать.

В>>Кстати, почему ты СУБД причисляешь к нижнему уровню? Это вполне себе полноценное звено системы, имеющее собственную логику.
S>Потому, что ниже нее уже ничего нету.

А выше что?

S>Это на самом деле неважно. Просто клиент должен показывать что-то типа "Нельзя удалить Склад №2 потому, что на нем числятся товары", а не всякое шаманство. И неважно, откуда приезжает эта строка — из базы данных, из middle tier, или ее клиент формирует. Просто информация о косяке должна передаваться снизу вверх в том объеме, который необходим и достаточен для выполнения задачи.
S>Если блин очередной уровень выкидывает строку типа "FK Violation" — то все, труба.

Видишь ли, проблема в том, что по дефолту именно в таком виде из базы оно и вылетает. И ничего кроме парсинга в таком случае не остается. Что, как ты сам сказал, довольно криво. Так что вопрос только в том, кидать ли из базы "magic code", с последующим формировании на сервере нужного типа исключения, с последующим формированием на клиенте нужного текстового сообщения или сформировать сообщение сразу в базе.

[...]
S>Не надо идти на поводу у лентяев из Inprise. Не надо считать следующий уровень интеллектуально ограниченным и скрывать от него информацию.

Причем здесь Inprise? Если Oracle там и выдает более осмысленную информацию об ошибке, то джавовские драйвера все равно превращают ее в абстрактный SQLException.