Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ
Шрифт:
Типы исключений
Может появиться три типа исключений.
* Ошибки SQL - т. е. сообщения SQL, имеющие отрицательное значение SQLCODE.
* Внутренние ошибки Firebird, которые имеют отношение к конкурирующему взаимодействию, данным, метаданным и условиям окружения. У них есть девяти- символьный код ошибки, обычно начинающийся с 3355, который уникально идентифицирует код GDSCODE. Большинство кодов GDSCODE попадают в обобщающие группы кодов SQLCODE, и при возникновении исключения вы обычно получаете и SQLCODE, и GDSCODE.
* Пользовательские исключения, которые вы объявляете как постоянные объекты базы данных и "вызываете"
Что такое исключение?
Исключение - это просто сообщение, которое генерируется, когда появляется ошибка.
Все предварительно определенные исключения - SQLCODE и GDSCODE - имеют ассоциированные с ними тексты сообщений. Сообщения по умолчанию на английском языке, но могут использоваться и другие языки. Существует небольшое количество версий сообщений на других языках (включая латинский!), другие или "находятся в работе", или "ожидают желающих поработать" [127] .
127
Как показывает практика, такие переводы не приносят ожидаемой пользы разработчикам. Сообщения сервера ориентированы на разработчика приложений, и даже будучи переведенными, слишком сложны для восприятия пользователем программы. Более грамотным является корректная обработка ошибок, возникающих на сервере, в коде клиентского приложения, и выдача пользователю осмысленных и понятных сообщений в контексте прикладной области. Не составляет сложености в это же время сохранять исходные сообщения от сервера в специальном файле для последующего анализа корректности работы приложения - Прим. науч. ред.
В Firebird существует синтаксис DDL для создания пользовательских исключений с текстами сообщений до 78 символов. В Firebird 1.5 вы можете расширить ваши пользовательские исключения во время выполнения, заменить текст сообщения, посылаемого по сети, в зависимости от контекста.
Создание исключения
Создание исключения является одним из самых простых элементов DDL. Синтаксис:
CREATE EXCEPTION имя-исключения <сообщение>;
Имя-исключения- обычный идентификатор Firebird до 31 символа длиной. Оно должно быть уникальным среди идентификаторов исключений, а в диалекте 3 может быть заключено в кавычки. Тогда имя будет чувствительным к регистру.
<сообщение> - заключенная в апострофы строка текста в наборе символов NONE. Из-за ограничения размера текст должен быть лаконичным. Например:
CREATE EXCEPTION NO_DOGS 'NO dogs allowed!'; COMMIT;
Оператор CREATE EXCEPTION должен быть подтвержден, как и любой другой оператор DDL.
Как пользователь SYSDBA или владелец исключения, которое используется в хранимых процедурах, вы можете изменять или удалять его в любое время. Если оно используется в триггере, вы можете его только изменять и изменять только текст сообщения. Не хранится никаких зависимостей для исключений, используемых в хранимых процедурах. Это создает проблему в случае, когда вы удаляете исключение и забываете убрать его из хранимых процедур - будет неловко получить исключение по причине отсутствия исключения!
Для удаления нашего исключения NO_DOGS введите:
DROP EXCEPTION NO_DOGS;
Для его изменения:
ALTER EXCEPTION NO_DOGS 'NO dogs allowed except Irish Wolfhounds!';
! ! !
СОВЕТ.
. ! .
Исключения в действии
Внутренне определенные исключения вызываются ядром сервера в ответ на соответствующие ошибки, которые требуют прекращения выполнения. Они охватывают большое количество условий, включая каждый вид нарушения ограничений, арифметические и строковые переполнения, ссылки на отсутствующие объекты, разрушение данных и т.д. Исключения SQLCODE и GDSCODE являются теми же самыми исключениями, что и исключения, используемые при появлении ошибок в процессе выполнения операций динамического SQL. Они описаны в приложении 10.
Пользовательские исключения, доступные только в модулях PSQL, не должны дублировать работу внутренне определенных исключений. Определяйте ваши исключения для использования там, где вы хотите в вашем коде выявлять ошибочные ситуации, которые нарушают ваши бизнес-правила. Три вида исключений изображены на рис. 32.1.
У нас был в главе 30 пример, в котором пользовательское исключение применялось в триггере для прекращения события, продолжение которого нарушило бы бизнес-правило. В этом случае хранимая процедура позаботится о том, чтобы убрать зависимости из организационной структуры при удалении служащего. Это было объявлено следующим образом:
CREATE EXCEPTION REASSIGN_SALES
'Reassign the sales records before deleting this employee.' ^
/* Переназначьте записи продаж перед удалением этого служащего */
COMMIT ^
Рис. 32.1. Стандартная реакция PSQL на исключения
В том месте, где используется это исключение, процедура проверяет, является ли данный служащий участником продаж в каком-либо документе продаж. Если да, то используется пользовательское исключение для завершения процедуры. Конечно, если возникает исключение, то все другие действия, выполненные в процедуре, отменяются.
BEGIN
IE (EXISTS (SELECT PO_NUMBER FROM SALES
WHERE SALES_REP = : emporium) ) THEN
EXCEPTION reassign_sales;
! ! !
ПРИМЕЧАНИЕ. В хранимых процедурах выбора выходные строки, которые уже были получены клиентом в предыдущих циклах FOR SELECT ... DO ... SUSPEND, остаются доступными для клиента. О механизме, работающем в этом случае, см. далее разд. "Оператор WHERE".
. ! .
Существуют случаи, когда возможно использовать пользовательское исключение как способ вмешательства в возникшую проблему и позволить процедуре продолжать выполнение. Вы можете перехватить исключение и написать код для его обработки прямо в этой процедуре. В следующем разделе рассматривается, каким образом эта техника перехвата и исправления может быть использована при исключении REASSIGN_SALES.