Книга: Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Диагностирование исключений

Диагностирование исключений

Основные причины возникновения ошибок при пересылке данных или подтверждении работы включают:

* конфликты блокировок;

* "плохие данные", полученные от интерфейса пользователя: арифметическое переполнение, деление на ноль в выражениях, пустые значения в полях, не допускающих пустых значений, несоответствие набора символов и т.д.;

* "хорошие данные", которые нарушают ограничение CHECK или другие проверки;

* нарушения первичного или внешнего ключей;

* и другие!

Firebird распознает большое количество различных (более того, поразительных!) исключений и возвращает код ошибки для их идентификации на двух уровнях:

* на высоком уровне существует переменная SQLCODE, определенная (более или менее, с ударением на "менее") в стандарте SQL;

* на более детальном уровне присутствует GDSCODE - индикатор большего размера, более точно определяющий тип исключений, которые сгруппированы на предыдущем уровне в типе SQLCODE.

В табл. 27.2 представлены значения стандартов SQL-89 и SQL-92, определенные для SQLCODE.

Таблица 27.2. Значения SQLCODE

Описание отрицательных значений SQLCODE для конкретных ошибок не содержится в стандартах. Отрицательные значения SQLCODE в Firebird являются довольно обобщенными, они представлены группами, которые в значительной степени получены случайно и очень часто своим составом изумляют. Например, можно установить, что значение SQLCODE -204 означает "нечто неизвестное", однако сам код ничего не говорит, что именно неизвестно.

Второй уровень, GDSCODE, предоставляет гораздо больше возможностей определения исключений. Каждый код GDSCODE является знаковым целым, константы которого представлены в iberror.h (или в interbase.msg, если вы используете версию 1.0.x)[105]. Как правило, сообщение GDSCODE достаточно точно указывает, что произошло[106]. В Firebird 1.5 значительно улучшена информация, передаваемая в сообщениях. Тем не менее GDSCODE предоставляет для приложений наиболее полезный механизм диагностики; вы можете преобразовать константы в пользовательские сообщения в вашем модуле на включающем языке для использования в обработчиках исключений.

В следующем примере приложение делает попытку добавить данные в таблицу, которая не существует:

INSERT INTO NON_EXISTENT (TEST)

VALUES ('ABCDEF');

Следующая информация об ошибке возвращается приложению (утилита администратора IB SQL в этом случае):

ISC ERROR CODE:335544569 <- GDSCODE

Dynamic SQL Error <- corresponding text from firebird.msg

SQL error code = -204 <- SQLCODE

Table unknown <- corresponding text from firebird,msg

NON_EXI STENT

Откуда приложение получает коды ошибок и сообщения? Ответ можно найти в векторе состояния ошибки (error status vector), в массиве, который передается в качестве параметра в большинство функций API. Эти функции возвращают состояние и коды ошибок клиенту вместе с соответствующими строками из файла сообщений Firebird[107]. API также предоставляет клиентским приложениям служебные функции для чтения содержимого векторов состояния ошибок в локальных буферах. Обработчики ошибок могут затем анализировать содержимое этих буферов и использовать полученную информацию для принятия решения, как поступить с исключением, а также выдать пользователю дружественное сообщение.

Заголовочный файл iberror.h в вашем каталоге /include содержит объявления, каждое из которых связано с SQLCODE и GDSCODE через символическую константу. Например, вот объявления констант для двух кодов ошибок из предыдущего примера:

. . .

#define isc_dsql_error 335544569L

. . .

#define isc_dsql_relation_err 335544580L <- an SQLCODE -204 error

Большинство из существующих языков высокого уровня и интерфейсов сценариев уже имеют транслированные объявления констант. Если вам нужна трансляция, рекомендуется обратиться к спискам поддержки. Полный список кодов SQLCODE, GDSCODE и стандартных сообщений на английском языке находится в приложении 10. Использование этих кодов ошибок и расширений языка в PSQL является темой главы 32.

Оглавление книги