Sqlcode oracle коды ошибок - Не ошибается лишь тот, кто ничего не делает!

К сожалению, многие программисты не склонны тратить время на то, чтобы застраховать свой код PL/SQL от всех возможных неожиданностей. У большинства из нас хватает проблем с написанием кода, реализующего положительные аспекты приложения: управление данными клиентов, построение счетов и т. д.; вдобавок это увеличивает объем работы. Всегда бывает дьявольски сложно — как с психологической точки зрения, так и в отношении расходования ресурсов — сосредоточиться на негативных аспектах работы системы: что, если пользователь нажмет не ту клавишу? А что делать, если база данных Oracle недоступна?

В результате мы пишем приложения PL/SQL, предназначенные для работы в «идеальном мире», где в программах не бывает ошибок, пользователи вводят лишь правильные данные, а все системы — и аппаратные и программные — всегда в полном порядке.

Конечно, жестокая реальность устанавливает свои правила: как бы вы ни старались, в приложении все равно отыщется еще одна ошибка. А ваши пользователи всегда постараются отыскать последовательность нажатий клавиш, от которых форма перестанет работать. Проблема проста: либо вы выделяете время на отладку и защиту своих программ, либо вам придется вести бесконечные бои в отступлении, принимая отчаянные звонки от пользователей и пытаясь потушить разгорающееся пламя.

К счастью, PL/SQL предоставляет достаточно мощный и гибкий механизм перехвата и обработки ошибок. И вполне возможно написать на языке PL/SQL такое приложение, которое полностью защитит от ошибок и всех пользователей, и базу данных Oracle.

Основные концепции и терминология обработки исключений

В языке PL/SQL ошибки всех видов интерпретируются как исключения — ситуации, которые не должны возникать при нормальном выполнении программы.

К числу исключений относятся:

ошибки, генерируемые системой (например, нехватка памяти или повторяющееся значение индекса);
ошибки, вызванные действиями пользователя;
предупреждения, выдаваемые приложением пользователю.

PL/SQL перехватывает ошибки и реагирует на них при помощи так называемых обработчиков исключений. Механизм обработчиков исключений позволяет четко отделить код обработки ошибок от основной логики программы, а также дает возможность реализовать обработку ошибок, управляемую событиями (в отличие от старой линейной модели). Независимо от того, как и по какой причине возникло конкретное исключение, оно всегда обрабатывается одним и тем же обработчиком в разделе исключений.

При возникновении ошибки — как системной, так и ошибки в приложении — в PL/SQL инициируется исключение. В результате выполнение блока прерывается, и управление передается для обработки в раздел исключений текущего блока, если он имеется. После обработки исключения возврат в тот блок, где исключение было инициировано, невозможен, поэтому управление передается во внешний блок.

Схема передачи управления при возникновении исключения показана на рис. 1.

Рис. 1. Архитектура обработки исключений

Существует два типа исключений:

Системное исключение определяется в Oracle и обычно инициируется исполняемым ядром PL/SQL, обнаружившим ошибку. Одним системным исключениям присваиваются имена (например, NO_DATA_FOUND), другие ограничиваются номерами и описаниями.
Исключение, определяемое программистом, актуально только для конкретного приложения. Имя исключения можно связать с конкретной ошибкой Oracle с помощью директивы компилятора EXCEPTION_INIT или же назначить ошибке номер и описание процедурой RAISE_APPLICATION_ERROR.

В этом блоге будут использоваться следующие термины:

Раздел исключений — необязательный раздел блока PL/SQL (анонимного блока, процедуры, функции, триггера или инициализационного раздела пакета), содержащий один или несколько обработчиков исключений. Структура раздела исключений очень похожа на структуру команды CASE, о которой рассказывалось в этом блоге.
Инициировать исключение — значит остановить выполнение текущего блока PL/SQL, оповещая исполняемое ядро об ошибке. Исключение может инициировать либо Oracle, либо ваш собственный программный код при помощи команды RAISE или процедуры RAISE_APPLICATION_ERROR.
Обработать исключение — значит перехватить ошибку, передав управление обработчику исключения. Написанный программистом обработчик может содержать код, который в ответ на исключение выполняет определенные действия (например, записывает информацию об ошибке в журнал, выводит сообщение для пользователя или передает исключение во внешний блок).
Область действия — часть кода (конкретный блок или весь раздел), в котором может инициироваться исключение, а также часть кода, инициируемые исключения которого могут перехватываться и обрабатываться соответствующим разделом исключений.
Передача исключения — процесс передачи исключения во внешний блок, если в текущем блоке это исключение не обработано.
Необработанное исключение — исключение, которое передается без обработки из «самого внешнего» блока PL/SQL. После этого управление передается исполнительной среде, которая уже сама определяет, как отреагировать на исключение (выполнить откат транзакции, вывести сообщение об ошибке, проигнорировать ее и т. д.).
Анонимное исключение — исключение, с которым связан код ошибки и описание. Такое исключение не имеет имени, которое можно было бы использовать в команде RAISE или секции WHEN обработчика исключений.
Именованное исключение — исключение, которому имя присвоено либо Oracle (в одном из встроенных пакетов), либо разработчиком. В частности, для этой цели можно использовать директиву компилятора EXCEPTION_INIT (в таком случае имя можно будет применять и для инициирования, и для обработки исключения).

Определение исключений

Прежде чем исключение можно будет инициировать и обрабатывать, его необходимо определить. В Oracle заранее определены тысячи исключений, большинство из которых имеют только номера и пояснительные сообщения. Имена присваиваются только самым распространенным исключениям.

Имена присваиваются в пакете STANDARD (одном из двух пакетов по умолчанию PL/SQL; другой пакет — DBMS_STANDARD), а также в других встроенных пакетах, таких как UTL_FILE и DBMS_SQL. Код, используемый Oracle для определения исключений (таких, как NO_DATA_FOUND), не отличается от кода, который вы будете использовать для определения или объявления ваших собственных исключений.

Это можно сделать двумя способами, описанными ниже.

Объявление именованных исключений

Исключения PL/SQL, объявленные в пакете STANDARD и в других встроенных пакетах, представляют внутренние (то есть системные) ошибки. Однако многие проблемы, с которыми будет сталкиваться пользователь приложения, актуальны только в этом конкретном приложении. Возможно, вашей программе придется перехватывать и обрабатывать такие ошибки, как «отрицательный баланс счета» или «дата обращения не может быть меньше текущей даты». Хотя эти ошибки имеют иную природу, нежели, скажем, ошибки «деления на нуль», они также относятся к разряду исключений, связанных с нормальной работой программы, и должны обрабатываться этой программой.

Одной из самых полезных особенностей обработки исключений PL/SQL является отсутствие структурных различий между внутренними ошибками и ошибками конкретных приложений. Любое исключение может и должно обрабатываться в разделе исключений независимо от типа ошибки.

Конечно, для обработки исключения необходимо знать его имя. Поскольку в PL/SQL имена пользовательским исключениям автоматически не назначаются, вы должны делать это самостоятельно, определяя исключения в разделе объявлений блока PL/SQL. При этом задается имя исключения, за которым следует ключевое слово EXCEPTION:

имя_исключения EXCEPTION;

Следующий раздел объявлений процедуры calc_annual_sales содержит два объявления исключений, определяемых программистом:

PROCEDURE calc_annual_sales(company_id_in IN company.company_id%TYPE)
IS
   invalid_company_id EXCEPTION;
   negative_balance EXCEPTION;

   duplicate_company BOOLEAN;
BEGIN
   ... исполняемые команды ...
EXCEPTION
   WHEN NO_DATA_FOUND -- системное исключение
    THEN
      ...
    WHEN invalid_company_id
    THEN

    WHEN negative_balance
    THEN
   ...
END;

По своему формату имена исключений схожи с именами других переменных, но ссылаться на них можно только двумя способами:

В команде RAISE, находящейся в исполняемом разделе программы (для инициирования исключения):

        RAISE invalid_company_id;

В секции WHEN раздела исключений (для обработки инициированного исключения):

        WHEN invalid_company_id THEN

Связывание имени исключения с кодом ошибки

В Oracle, как уже было сказано, имена определены лишь для самых распространенных исключений. Тысячи других ошибок в СУБД имеют лишь номера и снабжены пояснительными сообщениями. Вдобавок инициировать исключение с номером ошибки (в диапазоне от –20 999 до –20 000) может и разработчик приложения, воспользовавшись для этой цели процедурой RAISE_APPLICATION_ERROR (см. далее раздел «Инициирование исключений»).

Наличие в программном коде исключений без имен вполне допустимо, но такой код малопонятен и его трудно сопровождать. Допустим, вы написали программу, при выполнении которой Oracle выдает ошибку, связанную с данными, например ORA-01843: not a valid month. Для перехвата этой ошибки в программу включается обработчик следующего вида:

EXCEPTION
   WHEN OTHERS THEN
      IF SQLCODE = -1843 THEN

Но код получается совершенно непонятным. Чтобы сделать смысл этого кода более очевидным, следует воспользоваться директивой EXCEPTION_INIT.

Встроенная функция SQLCODE возвращает номер последней сгенерированной ошибки. Она будет рассмотрена далее в разделе «Обработка исключений» этой статьи.

Директива EXCEPTION_INIT

Директива компилятора EXCEPTION_INIT (команда, выполняемая во время компиляции) связывает идентификатор, объявленный с ключевым словом EXCEPTION, с внутренним кодом ошибки. Установив такую связь, можно инициировать исключение по имени и указать это имя в условии WHEN обработчика ошибок.

С директивой EXCEPTION_INIT условие WHEN, использованное в предыдущем примере, приводится к следующему виду:

PROCEDURE my_procedure
IS
   invalid_month EXCEPTION;
   PRAGMA EXCEPTION_INIT (invalid_month, −1843);
BEGIN
   ...
EXCEPTION
   WHEN invalid_month THEN

Жесткое кодирование номера ошибки становится излишним; имя ошибки говорит само за себя.

Директива EXCEPTION_INIT должна располагаться в разделе объявлений блока. Указанное в ней исключение должно быть объявлено либо в том же блоке, либо во внешнем, либо в спецификации пакета. Синтаксис директивы в анонимном блоке:

DECLARE
   имя_исключения EXCEPTION;
   PRAGMA EXCEPTION_INIT (имя_исключения, целое_число);

Здесь имя_исключения — имя исключения, объявляемого программистом, а целое_число — номер ошибки Oracle, которую следует связать с данным исключением. Номером ошибки может служить любое число со следующими ограничениями:

Номер ошибки не может быть равен –1403 (один из двух кодов ошибок NO_DATA_FOUND). Если вы по какой-либо причине захотите связать свое именованное исключение с этой ошибкой, передайте директиве EXCEPTION_INIT значение 100.
Номер ошибки не может быть равен 0 или любому положительному числу, кроме 100.
Номер ошибки не может быть отрицательным числом, меньшим –1 000 000.

Рассмотрим пример возможного объявления исключения. В приведенном ниже программном коде я объявляю и связываю исключение со следующим номером:

ORA-2292 integrity constraint (OWNER.CONSTRAINT) violated -
child record found.

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

PROCEDURE delete_company (company_id_in IN NUMBER)
IS
   /* Объявление исключения. */
   still_have_employees EXCEPTION;
   /* Имя исключения связывается с номером ошибки. */
   PRAGMA EXCEPTION_INIT (still_have_employees, 2292);
BEGIN
   /* Попытка удаления информации о компании. */
   DELETE FROM company
   WHERE company_id = company_id_in;
EXCEPTION
   /* При обнаружении дочерних записей инициируется это исключение! */
   WHEN still_have_employees 
   THEN
      DBMS_OUTPUT.PUT_LINE
         ('Пожалуйста, сначала удалите данные о служащих компании.');
END;

Именованные системные исключения

В Oracle для относительно небольшого количества исключений определены стандартные имена, задаваемые директивой компилятора EXCEPTION_INIT во встроенных пакетах. Самые важные и часто применяемые из них определены в пакете STANDARD. Так как это один из двух используемых по умолчанию пакетов PL/SQL, на определенные в нем исключения можно ссылаться без префикса с именем пакета. Например, если потребуется инициировать в программе исключение NO_DATA_FOUND, это можно сделать любой из следующих команд:

WHEN NO_DATA_FOUND THEN
WHEN STANDARD.NO_DATA_FOUND THEN

Определения стандартных именованных исключений встречаются и в других встроенных пакетах — например, в пакете DBMS_LOB, предназначенном для работы с большими объектами. Пример одного такого определения из указанного пакета:

invalid_argval EXCEPTION;
PRAGMA EXCEPTION_INIT(invalid_argval, -21560);

Поскольку пакет DBMS_LOB не используется по умолчанию, перед ссылкой на это исключение необходимо указать имя пакета:

WHEN DBMS_LOB.invalid_argval THEN...

Многие исключения, определенные в пакете STANDARD, перечислены в табл. 1. Для каждого из них приводится номер ошибки Oracle, значение, возвращаемое при вызове SQLCODE (встроенная функция SQLCODE, которая возвращает текущий код ошибки — см. раздел «Встроенные функции ошибок»), и краткое описание. Значение, возвращаемое SQLCODE, совпадает с кодом ошибки Oracle, с одним исключением: определяемый стандартом ANSI код ошибки NO_DATA_FOUND равен 100.

Имя исключения/Ошибка Oracle/SQLCODE	Описание
CURSOR_ALREADY_OPEN ORA-6511 SQLCODE = –6511	Попытка открытия курсора, который был открыт ранее. Перед повторным открытием курсор необходимо сначала закрыть
DUP_VAL_ON_INDEX ORA-00001 SQLCODE = −1	Команда `INSERT` или `UPDATE` пытается сохранить повторяющиеся значения в столбцах, объявленных с ограничением `UNIQUE`
INVALID_CURSOR ORA-01001 SQLCODE = −1001	Ссылка на несуществующий курсор. Обычно ошибка встречается при попытке выборки данных из неоткрытого курсора или закрытия курсора до его открытия
INVALID_NUMBER ORA-01722 SQLCODE = −1722	Выполняемая SQL-команда не может преобразовать символьную строку в число. Это исключение отличается от `VALUE_ERROR` тем, что оно инициируется только из SQL-команд
LOGIN_DENIED ORA-01017 SQLCODE = −1017	Попытка программы подключиться к СУБД Oracle с неверным именем пользователя или паролем. Исключение обычно встречается при внедрении кода PL/SQL в язык 3GL
NO_DATA_FOUND ORA-01403 SQLCODE = +100	Исключение инициируется в трех случаях: (1) при выполнении инструкции `SELECT INTO` (неявный курсор), которая не возвращает ни одной записи; (2) при ссылке на неинициализированную запись локальной таблицы PL/SQL; (3) при попытке выполнить операцию чтения после достижения конца файла при использовании пакета `UTL_FILE`
NOT_LOGGED ON ORA-01012 SQLCODE = −1012	Программа пытается обратиться к базе данных (обычно из инструкции DML) до подключения к СУБД Oracle
PROGRAM_ERROR ORA-06501 SQLCODE = −6501	Внутренняя программная ошибка PL/SQL. В сообщении об ошибке обычно предлагается обратиться в службу поддержки Oracle
STORAGE_ERROR ORA-06500 SQLCODE = −6500	Программе PL/SQL не хватает памяти или память по какой-то причине повреждена
TIMEOUT_ON_RESOURCE ORA-00051 SQLCODE = −51	Тайм-аут СУБД при ожидании ресурса
TOO_MANY_ROWS ORA-01422 SQLCODE = −1422	Команда SELECT INTO возвращает несколько записей, хотя должна возвращать лишь одну (в таких случаях инструкция SELECT включается в явное определение курсора, а записи выбираются по одной)
TRANSACTION_BACKED_OUT ORA-00061 SQLCODE = −61	Удаленная часть транзакции отменена либо при помощи явной инструкции `ROLLBACK`, либо в результате какого-то другого действия (например, неудачного выполнения команды SQL или DML в удаленной базе данных)
VALUE_ERROR ORA-06502 SQLCODE = −6502	Ошибка связана с преобразованием, усечением или проверкой ограничений числовых или символьных данных. Это общее и очень распространенное исключение. Если подобная ошибка содержится в инструкции SQL или DML, то в блоке PL/SQL инициируется исключение `INVALID_NUMBER`
ZERO_DIVIDE ORA-01476 SQLCODE = −1476	Попытка деления на ноль

Рассмотрим пример использования этой таблицы исключений. Предположим, ваша программа инициирует необрабатываемое исключение для ошибки ORA-6511. Заглянув в таблицу, вы видите, что она связана с исключением CURSOR_ALREADY_OPEN. Найдите блок PL/SQL, в котором произошла ошибка, и добавьте в него обработчик исключения

CURSOR_ALREADY_OPEN:
EXCEPTION
   WHEN CURSOR_ALREADY_OPEN
   THEN
      CLOSE my_cursor;
END;

Конечно, еще лучше было бы проанализировать весь программный код и заранее определить, какие из стандартных исключений в нем могут инициироваться. В таком случае вы сможете решить, какие исключения следует обрабатывать конкретно, какие следует включить в конструкцию WHEN OTHERS (см. далее), а какие оставить необработанными.

Область действия исключения

Областью действия исключения называется та часть программного кода, к которой оно относится, то есть блок, где данное исключение может быть инициировано. В следующей таблице указаны области действия исключений четырех разных типов.

Тип исключения	Область действия
Именованное системное исключение	Исключение является глобальным, то есть не ограничивается каким-то конкретным блоком кода. Системные исключения могут инициироваться и обрабатываться в любом блоке
Именованное исключение, определяемое программистом	Исключение может инициироваться и обрабатываться только в исполнительном разделе и разделе исключений, входящих в состав блока, где объявлено данное исключение (или в состав любого из вложенных в него блоков). Если исключение определено в спецификации пакета, то его областью действия являются все те программы, владельцы которых обладают для этого пакета привилегией `EXECUTE`
Анонимное системное исключение	Исключение может обрабатываться в секции `WHEN` `OTHERS` любого раздела исключений PL/SQL. Если присвоить ему имя, то его область действия будет такой же, как у именованного исключения, определяемого программистом
Анонимное исключение, определяемое программистом	Исключение определяется в вызове процедуры `RAISE_APPLICATION_ERROR`, а затем передается в вызывающую программу

Рассмотрим пример исключения overdue_balance, объявленного в процедуре check_account (таким образом, область его действия ограничивается указанной процедурой):

PROCEDURE check_account (company_id_in IN NUMBER)
IS
   overdue_balance EXCEPTION;
BEGIN
   ... исполняемые команды ...
   LOOP
      ...
      IF ... THEN
         RAISE overdue_balance;
      END IF;
   END LOOP;
EXCEPTION
   WHEN overdue_balance THEN ...
END;

С помощью команды RAISE исключение overdue_balance можно инициировать в процедуре check_account, но не в программе, которая ее вызывает. Например, для следующего анонимного блока компилятор выдает ошибку:

DECLARE
   company_id NUMBER := 100;
BEGIN
   check_account (100);
   EXCEPTION
      WHEN overdue_balance /* В PL/SQL такая ссылка недопустима. */
      THEN ...
END;

PLS-00201: identifier "OVERDUE_BALANCE" must be declared

Для приведенного выше анонимного блока процедура check_account является «черным ящиком». Все объявленные в ней идентификаторы, в том числе идентификаторы исключения, не видны для внешнего программного кода.

Инициирование исключений

Исключение может быть инициировано приложением в трех случаях:

Oracle инициирует исключение при обнаружении ошибки;
приложение инициирует исключение командой RAISE;
исключение инициируется встроенной процедурой RAISE_APPLICATION_ERROR.

Как Oracle инициирует исключения, вы уже знаете. Теперь давайте посмотрим, как это может сделать программист.

Команда RAISE

Чтобы программист имел возможность самостоятельно инициировать именованные исключения, в Oracle поддерживается команда RAISE. С ее помощью можно инициировать как собственные, так и системные исключения. Команда имеет три формы:

RAISE имя_исключения;
RAISE имя_пакета.имя_исключения;
RAISE;

Первая форма (без имени пакета) может инициировать исключения, определенные в текущем блоке (или в содержащем его блоке), а также системные исключения, объявленные в пакете STANDARD. Далее приводятся два примера, в первом из которых инициируется исключение, определенное программистом:

DECLARE
   invalid_id EXCEPTION; -- Все идентификаторы должны начинаться с буквы 'X'.
   id_value VARCHAR2(30);
BEGIN
   id_value := id_for ('SMITH');
   IF SUBSTR (id_value, 1, 1) != 'X'
   THEN
     RAISE invalid_id;
   END IF;
   ...
END;

При необходимости вы всегда можете инициировать системное исключение:

BEGIN
   IF total_sales = 0
   THEN
      RAISE ZERO_DIVIDE; -- Определено в пакете STANDARD
   ELSE
      RETURN (sales_percentage_calculation (my_sales, total_sales));
   END IF;
END;

Если исключение объявлено в пакете (но не в STANDARD) и инициируется извне, имя исключения необходимо уточнить именем пакета:

IF days_overdue (isbn_in, borrower_in) > 365
THEN
   RAISE overdue_pkg.book_is_lost;
END IF;

Третья форма RAISE не требует указывать имя исключения, но используется только в условии WHEN раздела исключений. Ее синтаксис предельно прост:

RAISE;

Используйте эту форму для повторного инициирования (передачи) перехваченного исключения:

EXCEPTION
   WHEN NO_DATA_FOUND
   THEN
      -- Используем общий пакет для сохранений всей контекстной
      -- информации: код ошибки, имя программы и т. д.
      errlog.putline (company_id_in);
      -- А теперь исключение NO_DATA_FOUND передается
      -- в родительский блок без обработки.
      RAISE;

Эта возможность особенно полезна в тех случаях, когда информацию об ошибке нужно записать в журнал, а сам процесс обработки возложить на родительский блок. Таким образом выполнение родительских блоков завершается без потери информации об ошибке.

Процедура RAISE_APPLICATION_ERROR

Для инициирования исключений, специфических для приложения, Oracle предоставляет процедуру RAISE_APPLICATION_ERROR (определенную в используемом по умолчанию пакете DBMS_STANDARD). Ее преимущество перед командой RAISE (которая тоже может инициировать специфические для приложения явно объявленные исключения) заключается в том, что она позволяет связать с исключением сообщение об ошибке.

При вызове этой процедуры выполнение текущего блока PL/SQL прекращается, а любые изменения аргументов OUT и IN OUT (если таковые имеются) отменяются. Изменения, внесенные в глобальные структуры данных (с помощью команды INSERT, UPDATE, MERGE или DELETE), такие как переменные пакетов и объекты баз данных, не отменяются. Для отката DML-команд необходимо явно указать в разделе обработки исключений команду ROLLBACK.

Заголовок этой процедуры (определяемый в пакете DBMS_STANDARD) выглядит так:

PROCEDURE RAISE_APPLICATION_ERROR (
   num binary_integer,
   msg varchar2,
   keeperrorstack boolean default FALSE);

Здесь num — номер ошибки из диапазона от –20 999 до –20 000 (только представьте: все остальные отрицательные числа Oracle резервирует для собственных исключений!); msg — сообщение об ошибке, длина которого не должна превышать 2048 символов (символы, выходящие за эту границу, игнорируются); аргумент keeperrorstack указывает, хотите ли вы добавить ошибку к уже имеющимся в стеке (TRUE), или заменить существующую ошибку (значение по умолчанию — FALSE).

Oracle выделяет диапазон номеров от –20 999 до –20 000 для пользовательских ошибок, но учтите, что в некоторых встроенных пакетах, в том числе в DBMS_OUTPUT и DBMS_DESCRIBE, номера от –20 005 до –20 000 все равно присваиваются системным ошибкам. За дополнительной информацией обращайтесь к документации пакетов.

Рассмотрим пример полезного применения этой встроенной процедуры. Допустим, мы хотим, чтобы сообщения об ошибках выдавались пользователям на разных языках. Создадим для них таблицу error_table и определим в ней язык каждого сообщения значением столбца string_language. Затем создается процедура, которая генерирует заданную ошибку, загружая соответствующее сообщение из таблицы с учетом языка текущего сеанса:

PROCEDURE raise_by_language (code_in IN PLS_INTEGER)
IS
   l_message error_table.error_string%TYPE;
BEGIN
   SELECT error_string
   INTO l_message
   FROM error_table
   WHERE error_number = code_in
      AND string_language = USERENV ('LANG');
   RAISE_APPLICATION_ERROR (code_in, l_message);
END;

Обработка исключений

Как только в программе возникает исключение, нормальное выполнение блока PL/SQL останавливается, и управление передается в раздел исключений. Затем исключение либо обрабатывается обработчиком исключений в текущем блоке PL/SQL, либо передается в родительский блок.

Чтобы обработать или перехватить исключение, нужно написать для него обработчик. Обработчики исключений располагаются после всех исполняемых команд блока, но перед завершающим ключевым словом END. Начало раздела исключений отмечает ключевое слово EXCEPTION:

DECLARE
   ... объявления ...
BEGIN
   ... исполняемые команды ...
[ EXCEPTION
... обработчики исключений ... ]
END;

Синтаксис обработчика исключений может быть таким:

WHEN имя_исключения [ OR имя_исключения ... ]
THEN
   исполняемые команды

или таким:

WHEN OTHERS
THEN
   исполняемые команды

В одном разделе исключений может быть несколько их обработчиков. Структура обработчиков напоминает структуру условной команды CASE.

Свойство	Описание
EXCEPTION WHEN NO_DATA_FOUND THEN исполняемые_команды1;	Если инициировано исключение `NO_DATA_FOUND`, выполнить первый набор команд
WHEN payment_overdue THEN исполняемые_команды2;	Если просрочена оплата, выполнить второй набор команд
WHEN OTHERS THEN исполняемые_команды3; END;	Если инициировано иное исключение, выполнить третий набор команд

Если имя, заданное в условии WHEN, совпадает с инициированным исключением, то это исключение обрабатывается соответствующим набором команд. Обратите внимание: исключения перехватываются по именам, а не по кодам ошибок. Но если инициированное исключение не имеет имени или его имя не соответствует ни одному из имен, указанных в условиях WHEN, тогда оно обрабатывается командами, заданными в секции WHEN OTHERS (если она имеется). Любая ошибка может быть перехвачена только одним обработчиком исключений. После выполнения команд обработчика управление сразу же передается из текущего блока в родительский или вызывающий блок.

Секция WHEN OTHERS не является обязательной. Когда она отсутствует, все необработанные исключения немедленно передаются в родительский блок, если таковой имеется. Секция WHEN OTHERS должна быть последним обработчиком исключений в блоке. Если разместить после нее еще одну секцию WHEN, компилятор выдаст сообщение об ошибке.

Встроенные функции ошибок

Прежде чем переходить к изучению тонкостей обработки ошибок, мы сначала вкратце познакомимся со встроенными функциями Oracle, предназначенными для идентификации, анализа и реагирования на ошибки, возникающие в приложениях PL/SQL.

SQLCODE

Функция SQLCODE возвращает код ошибки последнего исключения, инициированного в блоке. При отсутствии ошибок SQLCODE возвращает 0. Кроме того, SQLCODE возвращает 0 при вызове за пределами обработчика исключений.

База данных Oracle поддерживает стек значений SQLCODE. Допустим, к примеру, что функция FUNC инициирует исключение VALUE_ERROR (–6502). В разделе исключений FUNC вызывается процедура PROC, которая инициирует исключение DUP_VAL_ON_INDEX (–1). В разделе исключений PROC функция SQLCODE возвращает значение –1. Но когда управление передается в раздел исключений FUNC, SQLCODE будет возвращать –6502.

SQLERRM

Функция SQLERRM возвращает сообщение об ошибке для заданного кода ошибки. Если вызвать SQLERRM без указания кода ошибки, функция вернет сообщение, связанное со значением, возвращаемым SQLCODE. Например, если SQLCODE возвращает 0, функция SQLERRM вернет следующую строку:

ORA-0000: normal, successful completion

Если же SQLCODE возвращает 1 (обобщенный код ошибки для исключения, определяемого пользователем), SQLERRM вернет строку:

User-Defined Exception

Пример вызова SQLERRM для получения сообщения об ошибке для конкретного кода:

1  BEGIN
2     DBMS_OUTPUT.put_line (SQLERRM (-1403));
3* END;
SQL> /
ORA-01403: no data found

Максимальная длина строки, возвращаемой SQLERRM, составляет 512 байт (в некоторых ранних версиях Oracle — 255 байт). Из-за этого ограничения Oracle Corporation рекомендует вызывать функцию DBMS_UTILITY.FORMAT_ERROR_STACK, чтобы гарантировать вывод полной строки (эта встроенная функция не усекает текст до 2000 байт).

DBMS_UTILITY.FORMAT_ERROR_STACK

Эта встроенная функция, как и SQLERRM, возвращает сообщение, связанное с текущей ошибкой (то есть значение, возвращаемое SQLCODE). Ее отличия от SQLERRM:

Она возвращает до 1899 символов сообщения, что позволяет избежать проблем с усечением.
Этой функции не может передаваться код ошибки; соответственно, она не может использоваться для получения сообщения, соответствующего произвольному коду.

Как правило, эта функция вызывается в логике обработчика исключения для получения полного сообщения об ошибке.

Хотя в имя функции входит слово «stack», она не возвращает информацию о стеке ошибок, приведшем к строке, в которой изначально была инициирована ошибка. Эту задачу решает DBMS_UTILITY.FORMAT_ERROR_BACKTRACE.

DBMS_UTILITY.FORMAT_ERROR_BACKTRACE

Эта функция, появившаяся в Oracle10g, возвращает отформатированную строку с содержимым стека программ и номеров строк. Ее выходные данные позволяют отследить строку, в которой изначально была инициирована ошибка.

Тем самым заполняется весьма существенный пробел в функциональности PL/SQL. В Oracle9i и предшествующих версиях после обработки исключения в блоке PL/ SQL было невозможно определить строку, в которой произошла ошибка (возможно, самая важная информация для разработчика). Если программист хотел получить эту информацию, он должен был разрешить прохождение необработанного исключения, чтобы полная трассировочная информация ошибки была выведена на экран. Ситуация более подробно описана в следующем разделе.

DBMS_UTILITY.FORMAT_CALL_STACK

Функция возвращает отформатированную строку со стеком вызовов в приложении PL/SQL. Практическая полезность функции не ограничивается обработкой ошибок; она также пригодится для трассировки выполнения вашего кода.

В Oracle Database 12c появился пакет UTL_CALL_STACK, который также предоставляет доступ к стеку вызовов, стеку ошибок и информации обратной трассировки.

Подробнее о DBMS_UTILITY.FORMAT_ERROR_BACKTRACE

Функцию DBMS_UTILITY.FORMAT_ERROR_BACKTRACE следует вызывать в обработчике исключения. Она выводит содержимое стека выполнения в точке инициирования исключения. Таким образом, вызов DBMS_UTILITY.FORMAT_ERROR_BACKTRACE в разделе исключений на верхнем уровне стека позволит узнать, где именно в стеке вызовов произошла ошибка. Рассмотрим следующий сценарий: мы определяем процедуру proc3, которая вызывает процедуру proc2, а последняя, в свою очередь, вызывает proc1. Процедура proc1 инициирует исключение:

CREATE OR REPLACE PROCEDURE proc1 IS
BEGIN
   DBMS_OUTPUT.put_line ('выполнение proc1');
   RAISE NO_DATA_FOUND;
END;
/

CREATE OR REPLACE PROCEDURE proc2 IS
   l_str VARCHAR2 (30) := 'вызов proc1';
BEGIN
   DBMS_OUTPUT.put_line (l_str);
   proc1;
END;
/

CREATE OR REPLACE PROCEDURE proc3 IS
BEGIN
   DBMS_OUTPUT.put_line ('вызов proc2');
   proc2;
EXCEPTION
   WHEN OTHERS
   THEN
      DBMS_OUTPUT.put_line ('Стек ошибок верхнего уровня:');
      DBMS_OUTPUT.put_line (DBMS_UTILITY.format_error_backtrace);
END;
/

Единственной программой с обработчиком ошибок является внешняя процедура proc3. Вызов функции трассировки включен в обработчик WHEN OTHERS процедуры proc3. При выполнении этой процедуры будет получен следующий результат:

SQL> SET SERVEROUTPUT ON
SQL> BEGIN
2      DBMS_OUTPUT.put_line ('Proc3 -> Proc2 -> Proc1 backtrace');
3      proc3;
4    END;
5 /

Proc3 -> Proc2 -> Proc1 backtrace
вызов proc2
вызов proc1
выполнение proc1
Error stack at top level:
ORA-06512: at "SCOTT.PROC1", line 4
ORA-06512: at "SCOTT.PROC2", line 5
ORA-06512: at "SCOTT.PROC3", line 4

Как видите, функция трассировки выводит в начале стека номер строки proc1, в которой произошла исходная ошибка.

Часто исключение происходит где-то в глубине стека вызовов. Если вы хотите, чтобы оно было передано во внешний блок PL/SQL, вероятно, вам придется заново инициировать его в каждом обработчике стека блоков. Функция DBMS_UTILITY.FORMAT_ERROR_BACKTRACE выдает трассировку исполнения вплоть до последней команды RAISE в сеансе пользователя. Учтите, что вызов RAISE для конкретного исключения или повторное инициирование текущего исключения приводит к инициализации стека, выдаваемого DBMS_UTILITY.FORMAT_ERROR_BACKTRACE. Таким образом, если вы хотите использовать эту функцию, возможны два пути:

Вызовите функцию в разделе исключений блока, в котором была инициирована ошибка. Это позволит вам получить (и сохранить в журнале) номер ошибки, даже если исключение было заново инициировано в дальнейшей позиции стека.
Обойдите обработчики исключений в промежуточных программах вашего стека и вызовите функцию в разделе исключений внешней программы в стеке.

Только номер строки, пожалуйста

В реальном приложении трассировка ошибок может быть очень длинной. Как правило, специалиста, занимающегося отладкой или поддержкой, не интересует весь стек — достаточно только последнего элемента. Возможно, разработчику приложения стоит вывести эту важную информацию, чтобы пользователь мог немедленно и точно описать суть проблемы группе поддержки.

В такой ситуации необходимо разобрать строку с данными трассировки и извлечь из нее последний элемент. Я написал для этого специальную программу и оформил ее в пакет BT. В этом пакете реализован простой, понятный интерфейс:

PACKAGE bt
IS
   TYPE error_rt IS RECORD (
    program_owner all_objects.owner%TYPE
   , program_name all_objects.object_name%TYPE
   , line_number PLS_INTEGER
   );

   FUNCTION info (backtrace_in IN VARCHAR2)
      RETURN error_rt;

   PROCEDURE show_info (backtrace_in IN VARCHAR2);
END bt;

Тип записи error_rt содержит отдельное поле для каждого возвращаемого элемента трассировки (владелец программного модуля, имя программного модуля и номер строки в программе). Затем вместо того, чтобы вызывать функцию трассировки в каждом разделе исключения и разбирать ее результаты, я вызываю функцию bt.info и вывожу конкретную информацию об ошибке.

Полезные применения SQLERRM

Вы можете использовать DBMS_UTILITY.FORMAT_ERROR_STACK вместо SQLERRM, но это не означает, что функция SQLERRM совершенно неактуальна. В частности, она поможет вам получить ответ на следующие вопросы:

Является ли заданное число действительным кодом ошибки Oracle?
Какое сообщение соответствует коду ошибки?

Как упоминалось ранее в нашей статье, функция SQLERRM возвращает сообщение об ошибке для заданного кода. Но если передать SQLERRM недействительный код, исключение не инициируется. Вместо этого возвращается строка в одном из двух форматов:

Если число отрицательно:

        ORA-NNNNN: Message NNNNN not found; product=RDBMS; facility=ORA

Если число положительно или меньше −65535:

       -N: non-ORACLE exception

Этим обстоятельством можно воспользоваться для построения функций, возвращающих точную информацию о том коде, с которым вы работаете в настоящее время. Ниже приведена спецификация пакета с этими программами:

PACKAGE oracle_error_info
IS
   FUNCTION is_app_error (code_in IN INTEGER)
      RETURN BOOLEAN;
   FUNCTION is_valid_oracle_error (
      code_in IN INTEGER
      , app_errors_ok_in IN BOOLEAN DEFAULT TRUE
      , user_error_ok_in IN BOOLEAN DEFAULT TRUE
   )
   RETURN BOOLEAN;

PROCEDURE validate_oracle_error (
   code_in IN INTEGER
   , message_out OUT VARCHAR2
   , is_valid_out OUT BOOLEAN
   , app_errors_ok_in IN BOOLEAN DEFAULT TRUE
   , user_error_ok_in IN BOOLEAN DEFAULT TRUE
   );
END oracle_error_info;

Объединение нескольких исключений в одном обработчике

В одном условии WHEN можно оператором OR объединить несколько исключений — подобно тому, как этим оператором объединяются логические выражения:

WHEN invalid_company_id OR negative_balance
THEN

В одном обработчике также можно комбинировать имена пользовательских и системных исключений:

WHEN balance_too_low OR ZERO_DIVIDE OR DBMS_LDAP.INVALID_SESSION
THEN

Впрочем, применять оператор AND в такой комбинации нельзя, потому что в любой момент времени может быть инициировано только одно исключение.

Необработанные исключения

Исключение, инициированное в программе, но не обработанное в соответствующем разделе текущего или родительского блока PL/SQL, называется необработанным. PL/ SQL возвращает сообщение об ошибке, вызвавшей необработанное исключение, в ту среду, где была запущена данная программа. Эта среда (ею может быть SQL*Plus. Oracle Forms, программа на языке Java и т. д.) действует по ситуации. В частности, SQL*Plus осуществляет откат всех DML-инструкций, выполненных в родительском блоке.

Одним из важнейших моментов, связанных с проектированием архитектуры приложения, является вопрос о том, разрешается ли в нем использовать необработанные исключения. Такие исключения разными средами обрабатываются по-разному, и не всегда это делается корректно. Если ваша программа PL/SQL вызывается не из PL/SQL-среды, в ее «самом внешнем» блоке можно запрограммировать следующие действия:

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

Передача необработанного исключения

Блок, в котором может быть инициировано исключение, определяется правилами области действия исключений. В программе инициированное исключение распространяется в соответствии с определенными правилами.

Сначала PL/SQL ищет обработчик исключения в текущем блоке (анонимном блоке, процедуре или функции). Если такового нет, исключение передается в родительский блок. Затем PL/SQL пытается обработать исключение, инициировав его еще раз в родительском блоке. И так происходит в каждом внешнем по отношению к другому блоке до тех пор, пока все они не будут исчерпаны (рис. 2). После этого PL/SQL возвращает необработанное исключение в среду приложения, выполнившего «самый внешний» блок PL/SQL. И только теперь исключение может прервать выполнение основной программы.

Рис. 2. Передача исключений во вложенных блоках PL/SQL

Потеря информации об исключении

Структура процесса обработки локальных, определяемых программистом исключений в PL/SQL такова, что можно легко потерять информацию об исключении (то есть о том, какая именно произошла ошибка). Пример:

BEGIN
   <<local_block>>
   DECLARE
      case_is_not_made EXCEPTION;
   BEGIN
      ...
   END local_block;

Допустим, мы забыли включить в этот блок раздел исключений. Область действия исключения case_is_not_made ограничена блоком local_block. Если исключение не обрабатывается в данном блоке, оно передается в родительский, где нет никакой информации о нем. Известно только то, что произошла ошибка, а какая именно — неизвестно. Ведь все пользовательские исключения имеют один и тот же номер ошибки 1 и одно и то же сообщение «User Defined Exception» — если только вы не воспользуетесь директивой EXCEPTION_INIT, чтобы связать с объявленным исключением другой номер, и не присвоите ему другое сообщение об ошибке при вызове RAISE_APPLICATION_ERROR.

Таким образом, локально объявленные (и инициированные) исключения всегда следует обрабатывать по имени.

Примеры передачи исключения

Рассмотрим несколько примеров передачи исключений через внешние блоки. На рис. 3 показано, как исключение too_many_faults, инициированное во внутреннем блоке, обрабатывается в следующем — внешнем — блоке. Внутренний блок содержит раздел исключений, так что PL/SQL сначала проверяет, обрабатывается ли в этом разделе инициированное исключение too_many_faults.

Рис. 3. Передача исключений во вложенных блоках PL/SQL

А поскольку оно не обрабатывается, PL/SQL закрывает этот блок и инициирует исключение too_many_faults во внешнем блоке, обозначенном на рисунке как вложенный блок 1. (Используемые команды, расположенные после вложенного блока 2, не выполняются.) Затем просматривается раздел исключений этого блока с целью поиска обработчика исключения too_many_faults, который обрабатывает его и передает управление процедуре list_my_faults.

Обратите внимание: если исключение NO_DATA_FOUND будет инициировано в «самом внутреннем» блоке, то оно будет обработано в разделе исключений этого же блока. Затем управление передается во вложенный блок 1 и будут выполнены исполняемые команды, расположенные после вложенного блока 2.

На рис. 4 представлен пример обработки в «самом внешнем» блоке исключения, инициированного во внутреннем блоке. В изображенной ситуации раздел исключений присутствует только во внешнем блоке, поэтому когда во вложенном блоке 2 инициируется исключение too_many_faults, PL/SQL прекращает выполнение этого блока и инициирует данное исключение в его родительском блоке, то есть вложенном блоке 1. Но поскольку и у него нет раздела исключений, управление передается «самому внешнему» блоку, процедуре list_my_faults. В этой процедуре имеется раздел исключений, поэтому PL/ SQL проверяет его, находит обработчик исключения too_many_faults, выполняет имеющийся там код и передает управление программе, вызвавшей процедуру list_my_faults.

Рис. 4. Исключение, инициированное во вложенном блоке,
обрабатывается в «самом внешнем» блоке

Продолжение выполнения после исключений

Когда в блоке PL/SQL инициируется исключение, нормальная последовательность выполнения программы прерывается, а управление передается в раздел исключений. Вернуться к исполняемому разделу блока после возникновения в нем исключения уже не удастся. Впрочем, в некоторых ситуациях требуется именно это — продолжить выполнение программы после обработки исключения.

Рассмотрим следующий сценарий: требуется написать процедуру, которая применяет серию операций DML к разным таблицам (удаление из одной таблицы, обновление другой, вставка в последнюю таблицу). На первый взгляд код мог бы выглядеть примерно так:

PROCEDURE change_data IS
BEGIN
   DELETE FROM employees WHERE ... ;
   UPDATE company SET ... ;
   INSERT INTO company_history SELECT * FROM company WHERE ... ;
END;

Безусловно, процедура содержит все необходимые команды DML. Однако одно из требований к программе заключается в том, что при последовательном выполнении этих команд они должны быть логически независимы друг от друга. Другими словами, даже если при выполнении DELETE произойдет сбой, программа должна выполнить UPDATE и INSERT.

В текущей версии change_data ничто не гарантирует, что программа хотя бы попытается выполнить все три операции DML. Если при выполнении DELETE произойдет исключение, например, то выполнение всей программы прервется, а управление будет передано в раздел исключений (если он имеется). Остальные команды SQL при этом выполняться не будут.

Как обеспечить обработку исключения без прерывания программы? Для этого DELETE следует поместить в собственный блок PL/SQL. Рассмотрим следующую версию программы change_data:

PROCEDURE change_data 
IS
BEGIN
   BEGIN
      DELETE FROM employees WHERE ... ;
   EXCEPTION
      WHEN OTHERS THEN log_error;
   END;
   BEGIN
      UPDATE company SET ... ;
   EXCEPTION
      WHEN OTHERS THEN log_error;
   END;
   BEGIN
      INSERT INTO company_history SELECT * FROM company WHERE ... ;
   EXCEPTION
      WHEN OTHERS THEN log_error;
   END;
END;

В новом варианте программы, если при выполнении DELETE произойдет исключение, управление немедленно передается в раздел исключений. Но поскольку команда DELETE теперь находится в собственном блоке, она может иметь собственный раздел исключений. Условие WHEN OTHERS этого раздела обрабатывает ошибку без повторного инициирования этой или другой ошибки, после чего управление возвращается за пределы блока DELETE внешней процедуре change_data. Так как «активное» исключение отсутствует, выполнение продолжается во внешнем блоке со следующей команды процедуры. Программа входит в новый анонимный блок для команды UPDATE. Если при выполнении UPDATE произойдет ошибка, она будет перехвачена условием WHEN OTHERS раздела исключений UPDATE. Далее управление будет возвращено процедуре change_data, которая перейдет к выполнению команды INSERT (также содержащейся в собственном блоке).

На рис. 5 показано, как выполняется этот процесс для двух последовательно выполняемых команд DELETE.

Рис. 5. Последовательное выполнение DELETE с разными областями действия

Подведем итог: исключение, инициированное в исполняемом разделе, всегда обрабатывается в текущем блоке (при наличии подходящего обработчика). Любую команду можно заключить в «виртуальный блок», заключив ее между ключевыми словами BEGIN и END с определением раздела EXCEPTION. Это позволяет ограничить область действия сбоев в программе посредством определения «буферных» анонимных блоков.

Эту стратегию можно развить с выделением изолируемого кода в отдельные процедуры и функции. Конечно, именованные блоки PL/SQL тоже могут иметь собственные разделы исключений и предоставлять ту же защиту от общих сбоев. Важнейшее преимущество процедур и функций заключается в том, что они скрывают все команды BEGIN-EXCEPTION-END от основной программы. Программа лучше читается, код проще сопровождать и повторно использовать в других контекстах.

Существуют и другие способы продолжить выполнение после исключения DML — например, можно использовать конструкцию SAVE EXCEPTIONS с FORALL и LOG ERRORS в сочетании с DBMS_ERRORLOG.

Написание раздела WHEN OTHERS

Условие WHEN OTHERS включается в раздел исключений для перехвата всех исключений, не обработанных предшествующими обработчиками. Так как конкретный тип исключения изначально неизвестен, в WHEN OTHERS очень часто используются встроенные функции для получения информации о возникшей ошибке (такие, как SQLCODE и DBMS_UTILITY. FORMAT_ERROR_STACK).

В сочетании с WHEN OTHERS функция SQLCODE представляет средства для обработки разных видов исключений без применения директивы EXCEPTION_INIT. В следующем примере перехватываются два исключения категории «родитель/потомок», −1 и −2292, и для каждой ситуации выполняется подходящее действие:

PROCEDURE add_company (
   id_in IN company.ID%TYPE
   , name_in IN company.name%TYPE
   , type_id_in IN company.type_id%TYPE
)
IS
BEGIN
   INSERT INTO company (ID, name, type_id)
      VALUES (id_in, name_in, type_id_in);
EXCEPTION
   WHEN OTHERS
   THEN
      /*
      || Анонимный блок в обработчике исключения позволяет объявить
      || локальные переменные для хранения информации о кодах ошибок.
      */
      DECLARE
         l_errcode PLS_INTEGER := SQLCODE;
      BEGIN
         CASE l_errcode
         WHEN −1 THEN
            -- Дублирующееся значение уникального индекса. Повторяется либо
            -- первичный ключ, либо имя. Сообщить о проблеме
            -- и инициировать исключение заново.
            DBMS_OUTPUT.put_line
               ( 'идентификатор или имя компании уже используется. ID = '
               || TO_CHAR (id_in)
               || ' name = '
               || name_in
               );
            RAISE;
         WHEN −2291 THEN
            -- Родительский ключ не найден. Сообщить о проблеме
            -- и инициировать исключение заново.
            DBMS_OUTPUT.put_line (
               'Недопустимый идентификатор типа компании: ' || TO_CHAR (type_id_in));
            RAISE;
         ELSE
            RAISE;
         END CASE;
      END; -- Конец анонимного блока.
END add_company;

Будьте осторожны при использовании WHEN OTHERS — этот раздел способен «поглощать» ошибки, скрывая их от внешних блоков и пользователя. А точнее, обращайте внимание на обработчики WHEN OTHERS, которые не инициируют текущее исключение заново и не заменяют его другим исключением. Если WHEN OTHERS не передает исключение наружу, внешние блоки вашей программы не узнают о возникшей ошибке.

В Oracle Database 11g появилось новое предупреждение, которое помогает выявлять программы, игнорирующие ошибки или поглощающие их:

PLW-06009: procedure "string" OTHERS handler does not end in RAISE or RAISE_
APPLICATION_ERROR

Пример использования этого предупреждения:

SQL> ALTER SESSION SET plsql_warnings = 'enable:all'
2   /

SQL> CREATE OR REPLACE PROCEDURE plw6009_demo
2    AS
3    BEGIN
4       DBMS_OUTPUT.put_line ('I am here!');
5       RAISE NO_DATA_FOUND;
6    EXCEPTION
7       WHEN OTHERS
8       THEN
9          NULL;
10    END plw6009_demo;
11 /

SP2-0804: Procedure created with compilation warnings

SQL> SHOW ERRORS
Errors for PROCEDURE PLW6009_DEMO:

LINE/COL ERROR
-------- -----------------------------------------------------------------
7/9 PLW-06009: procedure "PLW6009_DEMO" OTHERS handler does not end
in RAISE or RAISE_APPLICATION_ERROR

Построение эффективной архитектуры управления ошибками

Механизм инициирования и обработки ошибок в PL/SQL отличается мощью и гибкостью, но он не лишен недостатков, которые могут создать проблемы для групп разработки, желающих реализовать надежную, последовательную, содержательную архитектуру управления ошибками. В частности, вы столкнетесь со следующими проблемами:

EXCEPTION — особая разновидность структуры данных PL/SQL. Переменные, объявленные с типом EXCEPTION, можно только инициировать и обрабатывать. Исключение нельзя передать в аргументе программы, с ним нельзя связать дополнительные атрибуты.
Повторное использование кода обработки исключений сильно затруднено. Из предыдущего пункта непосредственно следует другой факт: раз исключение нельзя передать в аргументе, разработчику приходится копировать код обработчика — конечно, такой способ написания кода никак не назовешь оптимальным.
Не существует формализованного способа объявления исключений, которые могут инициироваться программой. Например, в Java эта информация становится частью спецификации программы. Как следствие, разработчику приходится обращаться к коду реализации и искать в нем информацию о потенциальных исключениях — или же надеяться на лучшее.
Oracle не предоставляет средств организации и классификации исключений, относящихся к конкретному приложению, а просто резервирует (в основном) 1000 кодов в диапазоне от −20 999 до −20 000. Управлять этими значениями должен сам разработчик.

Давайте посмотрим, как преодолеть большинство из перечисленных трудностей.

Определение стратегии управления ошибками

Очень важно, чтобы еще до написания кода была выработана последовательная стратегия и архитектура обработки ошибок в приложении. Вот лишь некоторые вопросы, на которые необходимо ответить для этого:

Как и когда сохранять информацию об ошибках для последующего просмотра и исправления? Куда выводить информацию — в файл, в таблицу базы данных? выводить на экран?
Как и где сообщать об ошибках пользователю? Какую информацию должен получать пользователь? Как «перевести» часто невразумительные сообщения об ошибках, выдаваемые базой данных, на язык, понятный пользователям?

С этими общими вопросами тесно связаны более конкретные проблемы:

Следует ли включать раздел обработки исключений в каждый блок PL/SQL?
Следует ли включать раздел обработки исключений только в блок верхнего уровня или внешние блоки?
Как организовать управление транзакциями при возникновении ошибок? Сложность обработки исключений отчасти связана с тем, что на все эти вопросы не существует единственно правильного ответа. Все зависит (по крайней мере частично) от архитектуры приложения и режима его использования (например, пакетное выполнение или транзакции, управляемые пользователем). Но если вы сможете ответить на эти вопросы для своего приложения, я рекомендую «запрограммировать» стратегию и правила обработки ошибок в стандартном пакете (см. далее «Стандартизация обработки ошибок»).

Некоторые общие принципы, которые стоит принять во внимание:

Когда в коде происходит ошибка, получите как можно больше информации о контексте ее возникновения. Избыток информации — лучше, чем ее нехватка. Далее исключение можно передавать во внешние блоки, собирая дополнительную информацию по мере продвижения.
Избегайте применения обработчиков вида WHEN ошибка THEN NULL; (или еще хуже, WHEN OTHERS THEN NULL;). Возможно, для написания такого хода у вас имеются веские причины, но вы должны твердо понимать, что это именно то, что вам нужно, и документировать такое использование, чтобы о нем знали другие.
Там, где это возможно, используйте механизмы обработки ошибок PL/SQL по умолчанию. Избегайте написания программ, возвращающих коды состояния управляющей среде или вызывающим блокам. Применять коды состояния следует только в одной ситуации: если управляющая среда не способна корректно обрабатывать ошибки Oracle (в таком случае стоит подумать о смене управляющей среды!).

Стандартизация обработки разных типов исключений

Исключение всегда свидетельствует о критической ситуации? Вовсе нет. Некоторые исключения (например, ORA-00600) сообщают о том, что в базе данных возникли очень серьезные низкоуровневые проблемы. Другие исключения, такие как NO_DATA_FOUND, встречаются так часто, что мы воспринимаем их не как ошибки, а как условную логическую конструкцию («Если строка не существует, то выполнить следующие действия…»). Нужно ли различать эти категории исключений?

Коллеги-программисты научил меня очень полезной системе классификации исключений.

Преднамеренные исключения. Архитектура кода сознательно использует особенности работы исключения. Это означает, что разработчик должен предвидеть исключение и запрограммировать его обработку. Пример — UTL_FILE.GET_LINE.
Нежелательные исключения. Происходит ошибка, но ее возможность была предусмотрена заранее. Возможно, исключение даже не свидетельствует о возникновении проблемы. Пример команда SELECT INTO, инициирующая исключение NO_DATA_FOUND.
Непредвиденные исключения. Серьезные ошибки, указывающие на возникновение проблемы в приложении. Пример — команда SELECT INTO, которая должна вернуть строку для заданного первичного ключа, но вместо этого инициирует исключение TOO_MANY ROWS.

Давайте поближе познакомимся с примерами всех категорий, а затем поговорим о том, какую пользу вы можете извлечь из знания этих категорий.

Преднамеренные исключения

Разработчики PL/SQL могут использовать процедуру UTL_FILE.GET_LINE для чтения содержимого файла по строкам. Когда GET_LINE выходит за границу файла, инициируется исключение NO_DATA_FOUND. Так работает эта процедура. Итак, если я хочу прочитать все содержимое файла и сделать «что-то полезное», программа может выглядеть так:

PROCEDURE read_file_and_do_stuff (
   dir_in IN VARCHAR2, file_in IN VARCHAR2
)
IS
   l_file UTL_FILE.file_type;
   l_line VARCHAR2 (32767);
BEGIN
   l_file := UTL_FILE.fopen (dir_in, file_in, 'R', max_linesize => 32767);
   LOOP
      UTL_FILE.get_line (l_file, l_line);
      do_stuff;
   END LOOP;
EXCEPTION
   WHEN NO_DATA_FOUND
   THEN
      UTL_FILE.fclose (l_file);
      more_stuff_here;
END;

У этого цикла есть одна особенность: он не содержит команды EXIT. Кроме того, в разделе исключений выполняется дополнительная логика приложения (more_stuff_here). Цикл можно переписать в следующем виде:

LOOP
   BEGIN
      UTL_FILE.get_line (l_file, l_line);
      do_stuff;
   EXCEPTION
      WHEN NO_DATA_FOUND
      THEN
         EXIT;
   END;
END LOOP;

UTL_FILE.flcose (l_file);
more_stuff_here;

Теперь цикл содержит команду EXIT, но код стал более громоздким.

Подобные конструкции приходится использовать при работе с кодом, намеренно инициирующем исключения в своей архитектуре. Дополнительная информация о том, как следует поступать в подобных случаях, приводится в следующих разделах.

Нежелательные и непредвиденные исключения

Я рассматриваю эти две категории вместе, потому что приводимые примеры (NO_DATA_FOUND и TOO_MANY_ROWS) тесно связаны между собой. Предположим, я хочу написать функцию, возвращающую полное имя работника (в формате фамилия запятая имя) для заданного значения первичного ключа. Проще всего это сделать так:

FUNCTION fullname (
   employee_id_in IN employees.employee_id%TYPE
)
   RETURN VARCHAR2
IS
   retval VARCHAR2 (32767);
BEGIN
   SELECT last_name || ',' || first_name
    INTO retval
    FROM employees
   WHERE employee_id = employee_id_in;

   RETURN retval;
END fullname;

Если вызвать эту программу с кодом работника, отсутствующим в таблице, база данных инициирует исключение NO_DATA_FOUND. Если же вызвать ее с кодом работника, встречающимся в нескольких строках таблицы, будет инициировано исключение TOO_MANY_ROWS. Один запрос, два разных исключения — нужно ли рассматривать их одинаково? Вероятно, нет. Описывают ли эти два исключения похожие группы проблем? Давайте посмотрим:

NO_DATA_FOUND — совпадение не найдено. Исключение может указывать на наличие серьезной проблемы, но не обязательно. Возможно, в большинстве обращений к базе данных совпадение не будет обнаруживаться, и я буду вставлять в базу данные нового работника. В общем, исключение нежелательно, но в данном случае оно даже не указывает на возникновение ошибки.
TOO_MANY_ROWS — в базе данных возникла серьезная проблема с ограничением первичного ключа. Трудно представить себе ситуацию, в которой это было бы нормально или просто «нежелательно». Нет, нужно прервать работу программы и привлечь внимание пользователя к совершенно непредвиденной, критической ошибке.

Как извлечь пользу из этой классификации

Надеюсь, вы согласитесь, что такая классификация полезна. Приступая к построению нового приложения, постарайтесь по возможности определиться со стандартным подходом, который будет применяться вами (и всеми остальными участниками группы) для каждого типа исключений. Затем для каждого исключения (которое необходимо обработать или хотя бы учитывать заранее при написании кода) решите, к какой категории относится, и примените уже согласованный подход. Все это поможет сделать ваш код более последовательным, и повысит эффективность вашей работы. Приведу несколько рекомендаций для трех типов исключений.

Преднамеренные исключения. Пишите код, учитывающий возможность возникновения таких исключений. Прежде всего постарайтесь избежать размещения логики приложения в разделе исключений. Раздел исключений должен содержать только код, относящийся к обработке ошибки: сохранение информации об ошибке в журнале, повторное инициирование исключения и т. д. Программисты не ожидают увидеть логику приложения в разделе исключений, поэтому им будет намного труднее разобраться в таком коде и обеспечить его сопровождение.
Нежелательные исключения. Если в каких-то обстоятельствах пользователь кода, инициировавшего исключения, не будет интерпретировать ситуацию как ошибку, не передавайте исключения наружу без обработки. Вместо этого верните значение или флаг состояния, показывающий, что исключение было обработано. Далее пользователь программы может сам решить, должна ли программа завершиться с ошибкой. А еще лучше — почему бы не разрешить стороне, вызывающей вашу программу, решить, нужно ли инициировать исключение, и если не нужно — какое значение должно передаваться для обозначения возникшего исключения?
Непредвиденные исключения. А теперь начинается самое неприятное. Все непредвиденные ошибки должны быть сохранены в журнале с максимумом возможной контекстной информации, которая поможет понять причины возникновения ошибки. Затем программа должна завершиться с необработанным исключением (обычно тем же), инициированным из программы; для этого можно воспользоваться командой RAISE. Исключение заставит вызвавшую программу прервать работу и обработать ошибку.

Коды ошибок, связанные с конкретным приложением

Используя команду RAISE_APPLICATION_ERROR для инициирования ошибок, относящихся к конкретному приложению, вы несете полную ответственность за управление кодами ошибок и сообщениями. Это быстро становится хлопотным и непростым делом («Так, какой бы код мне выбрать? Пожалуй, –20 774 — вроде бы такого еще не было?»).

Чтобы упростить управление кодами ошибок и предоставить последовательный интерфейс, через который разработчики смогут обрабатывать серверные ошибки, постройте таблицу со всеми используемыми кодами ошибок −20 NNN, сопутствующими именами исключений и сообщениями об ошибках.

Разработчик может просмотреть уже определенные ошибки на экране и выбрать ту из них, которая лучше всего подходит для конкретной ситуации.

Также можно попытаться полностью избегать диапазон −20 NNN для ошибок приложений. Почему бы не воспользоваться положительными числами? Из положительного цело-численного поддиапазона Oracle использует только 1 и 100. Теоретически возможно, что когда-нибудь Oracle будет использовать и другие положительные числа, но это весьма маловероятно. В распоряжении разработчиков остается великое множество кодов ошибок.

В частности, я пошел по этому пути при проектировании Quest Error Manager (QEM) — бесплатной программы управления ошибками. В Quest Error Manager вы можете определять свои ошибки в специальной таблице. Ошибка определяется именем и/ или кодом. Коды ошибок могут быть положительными или отрицательными. Если код ошибки положителен, при инициировании исключения QEM использует команду RAISE_APPLICATION_ERROR для инициирования обобщенного исключения (обычно −20 000). Информация о текущем коде ошибки приложения встраивается в сообщение об ошибке, которое может быть расшифровано программой-получателем.

Упрощенная реализация этого подхода представлена в пакете обработки ошибок errpkg. pkg, описанном в следующем разделе блога.

Стандартизация обработки ошибок

Обязательным элементом любого профессионально написанного приложения является надежная и согласованная схема обработки ошибок. Согласованность в этом вопросе важна как для пользователя, так и для разработчика. Если при возникновении ошибки пользователю предоставляется понятная, хорошо структурированная информация, он сможет более подробно рассказать об ошибке службе поддержки и будет более уверенно чувствовать себя при работе с приложением. Если приложение всегда обрабатывает и протоколирует ошибки определенным образом, программистам, занимающимся его поддержкой и сопровождением, будет легче их найти и устранить.

Все кажется вполне очевидным, не так ли? К сожалению, на практике (и особенно в больших группах разработчиков) все происходит несколько иначе. Очень часто каждый разработчик идет своим путем, следуя личным принципам и приемам, сохраняя информацию в произвольно выбранном формате и т. д. Одним словом, без стандартизации отладка и сопровождение приложений оборачиваются сущим кошмаром. Рассмотрим типичный пример:

EXCEPTION
   WHEN NO_DATA_FOUND
   THEN
      v_msg := 'Нет компании с идентификатором '||TO_CHAR (v_id);
      v_err := SQLCODE;
      v_prog := 'fixdebt';
      INSERT INTO errlog VALUES
         (v_err,v_msg,v_prog,SYSDATE,USER);
      WHEN OTHERS
   THEN
      v_err := SQLCODE;
      v_msg := SQLERRM;
      v_prog := 'fixdebt';
      INSERT INTO errlog VALUES
         (v_err,v_msg,v_prog,SYSDATE,USER);
      RAISE;

На первый взгляд код выглядит вполне разумно. Если компания с заданным идентификатором не найдена, мы получаем значение SQLCODE, задаем имя программы и сообщение и записываем строку с информацией об ошибке в таблицу ошибок. Выполнение родительского блока продолжается, поскольку ошибка не критична. Если происходит любая другая ошибка, получаем ее код и соответствующее сообщение, задаем имя программы и записываем строку с информацией об ошибке в таблицу ошибок, а затем передаем исключение в родительский блок, чтобы остановить его выполнение (поскольку неизвестно, насколько критична эта ошибка).

Что же здесь не так? Чтобы подробно объяснить суть проблемы, достаточно взглянуть на код. В нем жестко закодированы все действия по обработке ошибок. В результате (1) код получается слишком объемистым, (2) его придется полностью переписывать при изменении схемы обработки ошибок. Обратите внимание еще и на тот факт, что информация об ошибке записывается в таблицу базы данных. Это означает, что запись в журнале становится частью логической транзакции. И если потребуется выполнить откат транзакции, записи в журнале ошибок будут утеряны.

Существует несколько способов избежать потери информации: можно записывать данные в файл или использовать автономные транзакции для сохранения журнала вне основной транзакции. Но как бы то ни было, код в случае его изменения придется исправлять в сотнях разных мест.

А теперь посмотрите, как этот же раздел исключений оформляется при использовании стандартизированного пакета:

EXCEPTION
   WHEN NO_DATA_FOUND
   THEN
      errpkg.record_and_continue (
      SQLCODE, 'Нет компании с идентификатором ' || TO_CHAR (v_id));
   WHEN OTHERS
   THEN
      errpkg.record_and_stop;
END;

Такой пакет обработки ошибок скрывает все подробности реализации; вы просто решаете, какая из процедур-обработчиков должна использоваться в конкретном случае, просматривая спецификацию пакета. Если требуется сохранить информацию об ошибке и продолжить работу, вызывается программа record_and_continue. Если же нужно сохранить информацию об ошибке и прервать выполнение родительского блока, вызывается программа record_and_stop. Мы не знаем, как эти программы сохраняют информацию об ошибке, как они останавливают работу родительского блока, то есть передают исключение, но для нас это и не важно. Главное, что все происходит так, как определено стандартами приложения.

Это дает вам возможность уделить больше времени разработке более интересных элементов приложения и не заниматься административной рутиной.

Имеется файл errpkg.pkg с прототипом стандартизированного пакета обработки ошибок. Правда, прежде чем использовать его в приложениях, вам необходимо будет завершить его реализацию; это поможет составить ясное представление о том, как конструируются подобные утилиты.

Вы также можете воспользоваться намного более мощным (и тоже бесплатным) средством обработки ошибок Quest Error Manager. Важнейшая концепция, заложенная в основу QEM, заключается в возможности перехвата и протоколирования экземпляров ошибок, не только ошибок Oracle. QEM состоит из пакета PL/SQL и четырех таблиц для хранения информации об ошибках, возникающих в приложениях.

Работа с «объектами» исключений

Реализация типа данных EXCEPTION в Oracle имеет свои ограничения, о которых было рассказано выше. Исключение состоит из идентификатора (имени), с которым связывается числовой код и сообщение. Исключение можно инициировать, его можно обработать… и все. Теперь представьте, как та же ситуация выглядит в Java: все ошибки являются производными от единого класса Exception. Этот класс можно расширить, дополняя его новыми характеристиками, которые вы хотите отслеживать (стек ошибок, контекстные данные и т. д.). Объект, созданный на основе класса Exception, ничем не отличается от любых других объектов Java. Разумеется, он может передаваться в аргументах методов.

PL/SQL не позволяет делать ничего подобного со своими исключениями. Впрочем, этот факт не мешает вам реализовать свой «объект» исключения. Для этого можно воспользоваться объектными типами Oracle или реляционной таблицей, содержащей информацию об ошибке. Независимо от выбранной реализации очень важно различать определение ошибки (код ошибки –1403, имя «данные не найдены», причина — «неявный курсор не нашел ни одной записи») и ее конкретный экземпляр (я попытался найти компанию с указанным именем, ни одной строки не найдено). Иначе говоря, существует всего одно определение исключения NO_DATA_FOUND, которое может существовать во множестве экземпляров. Oracle не различает эти два представления ошибки, но для нас это безусловно необходимо.

Пример простой иерархии объектов исключений продемонстрирует этот момент. Начнем с базового объектного типа всех исключений:

CREATE TYPE exception_t AS OBJECT (
   name VARCHAR2(100),
   code INTEGER,
   description VARCHAR2(4000),
   help_text VARCHAR2(4000),
   recommendation VARCHAR2(4000),
   error_stack CLOB,
   call_stack CLOB,
   created_on DATE,
   created_by VARCHAR2(100)
   )
   NOT FINAL;
/

Затем базовый тип исключения расширяется для ошибок динамического SQL посредством добавления атрибута sql_string. При обработке ошибок динамического SQL очень важно сохранить строку, создавшую проблемы, для анализа в будущем:

CREATE TYPE dynsql_exception_t UNDER exception_t (
   sql_string CLOB )
   NOT FINAL;
/

А вот другой подтип exception_t, на этот раз относящийся к конкретной сущности приложения — работнику. Исключение, инициируемое для ошибок, относящихся к работникам, будет включать идентификатор работника и внешний ключ нарушенного правила:

CREATE TYPE employee_exception_t UNDER exception_t (
   employee_id INTEGER,
   rule_id INTEGER );
/

Полная спецификация иерархии объектов ошибок включает методы супертипа исключения, предназначенные для вывода информации об ошибках или ее записи в репозиторий. Вы можете самостоятельно завершить иерархию, определенную в файле exception.ot.

Если вы не хотите работать с объектными типами, попробуйте использовать подход, использованный мной в QEM: я определяю таблицу определений ошибок (Q$ERROR) и другую таблицу экземпляров ошибок (Q$ERROR_INSTANCE), которая содержит информацию о конкретных экземплярах ошибок. Все контекстные данные экземпляра ошибки сохраняются в таблице Q$ERROR_CONTEXT.

Пример кода, который мог бы быть написан для QEM API:

WHEN DUP_VAL_ON_INDEX
THEN
   q$error_manager.register_error (
      error_name_in => 'DUPLICATE-VALUE'
      ,err_instance_id_out => l_err_instance_id
      );
   q$error_manager.add_context (
      err_instance_id_in => l_err_instance_id
      ,name_in => 'TABLE_NAME', value_in => 'EMPLOYEES'
      );
   q$error_manager.add_context (
      err_instance_id_in => l_err_instance_id
      ,name_in => 'KEY_VALUE', value_in => l_employee_id
      );
   q$error_manager.raise_error_instance (
      err_instance_id_in => l_err_instance_id);
END;

Если ошибка повторяющегося значения была вызвана ограничением уникального имени, я получаю идентификатор экземпляра ошибки DUPLICATE-VALUE. (Да, все верно: я использую имена ошибок, полностью обходя все проблемы, связанные с номерами ошибок.) Затем я добавляю контекстную информацию экземпляра (имя таблицы и значение первичного ключа, вызвавшее проблему). В завершение инициируется экземпляр ошибки, в результате чего исключение передается в следующий наружный блок.

По аналогии с передачей данных из приложения в репозиторий ошибок через API, вы также можете получить информацию об ошибке при помощи процедуры get_error_info.

Пример:

BEGIN
   run_my_application_code;
EXCEPTION
   WHEN OTHERS
   THEN
      DECLARE
         l_error q$error_manager.error_info_rt;
      BEGIN
         q$error_manager.get_error_info (l_error);
         DBMS_OUTPUT.put_line ('');
         DBMS_OUTPUT.put_line ('Error in DEPT_SAL Procedure:');
         DBMS_OUTPUT.put_line ('Code = ' || l_error.code);
         DBMS_OUTPUT.put_line ('Name = ' || l_error.NAME);
         DBMS_OUTPUT.put_line ('Text = ' || l_error.text);
         DBMS_OUTPUT.put_line ('Error Stack = ' || l_error.error_stack);
      END;
END;

Это лишь два из многих способов преодоления ограничений типа EXCEPTION в PL/SQL. Мораль: ничто не заставляет вас мириться с ситуацией по умолчанию, при которой с экземпляром ошибки связывается только код и сообщение.

Создание стандартного шаблона для обобщенной обработки ошибок

Невозможность передачи исключений программе сильно усложняет совместное использование разделов обработки ошибок в разных блоках PL/SQL. Одну и ту же логику обработчика нередко приходится записывать снова и снова, особенно при работе с конкретными функциональными областями — скажем, файловым вводом/ выводом с UTL_FILE. В таких ситуациях стоит выделить время на создание шаблонов обработчиков.

Давайте поближе познакомимся с UTL_FILE. До выхода Oracle9i Database Release 2 в спецификации пакета UTL_FILE определялся набор исключений. Однако компания Oracle не стала предоставлять коды этих исключений через директиву EXCEPTION_INIT. А без обработки исключений UTL_FILE по имени SQLCODE не сможет разобраться, что пошло не так. Вероятно, в такой ситуации для программ UTL_FILE можно создать шаблон, часть которого выглядит так:

DECLARE
   l_file_id UTL_FILE.file_type;
PROCEDURE cleanup (file_in IN OUT UTL_FILE.file_type
   ,err_in IN VARCHAR2 := NULL)
IS
BEGIN
   UTL_FILE.fclose (file_in);
   IF err_in IS NOT NULL
   THEN
      DBMS_OUTPUT.put_line ('Обнаружена ошибка UTL_FILE:');
      DBMS_OUTPUT.put_line (err_in);
   END IF;
END cleanup;

BEGIN
   -- Здесь размещается тело программы.
   -- Перед выходом необходимо прибрать за собой ...
   cleanup (l_file_id);
EXCEPTION
   WHEN UTL_FILE.invalid_path
   THEN
      cleanup (l_file_id, 'invalid_path');
      RAISE;
   WHEN UTL_FILE.invalid_mode
   THEN
      cleanup (l_file_id, 'invalid_mode');
      RAISE;
END;

Основные элементы шаблона:

Программа выполнения завершающих действий, пригодная для повторного использования; гарантирует, что текущий файл будет закрыт до потери дескриптора файла.
Преобразование именованного исключения в строку, которую можно сохранить в журнале или вывести на экран, чтобы пользователь точно знал, какая ошибка была инициирована.

Рассмотрим еще один пример шаблона, который удобно использовать при работе с UTL_FILE. В Oracle9i Database Release 2 появилась программа FREMOVE для удаления файлов. Пакет UTL_FILE предоставляет исключение DELETE_FAILED, инициируемое тогда, когда FREMOVE не удается удалить файл. После тестирования программы я обнаружил, что FREMOVE может инициировать несколько возможных исключений, в числе которых:

UTL_FILE.INVALID_OPERATION — удаляемый файл не существует.
UTL_FILE.DELETE_FAILED — у вас (или у процесса Oracle) недостаточно привилегий для удаления файла, или попытка завершилась неудачей по другой причине.

Начиная с Oracle9i Database Release 2, UTL_FILE назначает коды ошибок всем своим исключениям, но вы все равно должны проследить за тем, чтобы при возникновении ошибки файлы были закрыты, и организовать последовательную обработку ошибок.

Итак, при использовании UTL_FILE.FREMOVE следует включать раздел обработчика исключения, который различает эти две ошибки:

BEGIN
   UTL_FILE.fremove (dir, filename);
EXCEPTION
   WHEN UTL_FILE.delete_failed
   THEN
      DBMS_OUTPUT.put_line (
         'Ошибка при попытке удаления: ' || filename || ' в ' || dir);
      -- Выполнение соответствующих действий...
      WHEN UTL_FILE.invalid_operation
      THEN
         DBMS_OUTPUT.put_line (
            'Не удалось найти и удалить: ' || filename || ' в ' || dir);
         -- Выполнение соответствующих действий...
END;

Оптимальная организация обработки ошибок в PL/SQL

Без унифицированной качественной методологии обработки ошибок очень трудно написать приложение, которое было бы удобным в использовании и одновременно простым в отладке.

Архитектура обработки ошибок в Oracle PL/SQL предоставляет очень гибкие средства для определения, инициирования и обработки ошибок. Однако у нее имеются свои ограничения, вследствие чего встроенную функциональность обычно приходится дополнять таблицами и кодами ошибок, специфическими для конкретного приложения.

Для решения проблемы обработки ошибок рекомендуется предпринять следующие действия:

Тщательно разберитесь в системе инициирования и обработки ошибок в PL/SQL. Далеко не во ее аспекты интуитивно понятны. Простейший пример: исключение, инициированное в секции объявлений, не будет обрабатываться секцией исключений текущего блока.
Выберите общую схему обработки ошибок в вашем приложении. Где и как будут обрабатываться ошибки? Какая информация об ошибке будет сохраняться и как это будет сделано? Как исключения будут передаваться в управляющую среду? Как будут обрабатываться намеренные и непредвиденные ошибки?
Постройте стандартную инфраструктуру, которая будет использоваться всеми разработчиками проекта. Инфраструктура должна включать таблицы, пакеты и, возможно, объектные типы, а также четко определенный процесс использования всех перечисленных элементов. Не останавливайтесь на ограничениях PL/ SQL. Найдите обходные пути, расширяя модель обработки ошибок.
Создайте шаблоны, которые могут использоваться всеми участниками вашей группы. Всегда проще следовать готовому стандарту, чем самостоятельно писать код обработки ошибок.

Жду отклика на статью. Что понравилось? Что нет?

Вас заинтересует / Intresting for you:

Источник

This page contains an Oracle SQLCODE list of errors that you may encounter when working with Oracle SQL. The codes are ANSI-standard, which means you should find them with all relational databases.s

The list of SQLCODE messages is shown below.

Code Explanation -7 Statement contains the illegal character character -10 The string constant beginning string is not terminated -29 Into clause required -60 Invalid type specification : spec -84 Unacceptable SQL statement -101 The statement is too long or too complex -102 Literal string is too long. string begins string -103 literal is an invalid numeric literal -104 Illegal symbol “token”. some symbols that might be legal are: token-list -105 Invalid string -107 The name name is too long. maximum allowable size is size -109 clause clause is not permitted -110 Invalid hexadecimal literal beginning string -111 A column function does not include a column name -112 The operand of a column function is another column function -113 Invalid character found in string, reason code – nnn -114 The location name location does not match the current server -115 A predicate is invalid because the comparison operator operator is followed by a parenthesized list or by any or all without a subquery -117 The number of insert values is not the same as the number of object columns -118 The object table or view of the insert, delete, or update statement is also identified in a from clause -119 A column identified in a having clause is not included in the group by clause -120 A where clause or set clause includes a column function -121 The column name is identified more than once in the insert or update statement -122 A select statement with no group by clause contains a column name and a column function in the select clause or a column name is contained in the select clause but not in the group by clause -125 An integer in the order by clause does not identify a column of the result -126 The select statement contains both an update clause and an order by clause -127 Distinct is specified more than once in a subselect -128 Invalid use of NULL in a predicate -129 The statement contains too many table names -130 The escape clause consists of more than one character, or the string pattern contains an invalid occurrence of the escape character -131 Statement with like predicate has incompatible data types -132 A like predicate is invalid because the second operand is not a string -133 A column function in a subquery of a having clause is invalid because all column references in its argument are not correlated to the group by result that the having clause is applied to -134 Improper use of long string column column-name or a host variable of maximum length greater than 254 -136 Sort cannot be executed because the sort key length is greater than 4000 bytes -137 Result of concatenation too long -138 The second or third argument of the substr function is out of range -144 Invalid section number number -150 The object of the insert, delete, or update statement is a view for which the requested operation is not permitted -151 The update statement is invalid because the catalog description of column column-name indicates that it cannot be updated -152 The drop clause clause in the alter statement is invalid because constraint-name is a constraint-type -153 The create view statement does not include a required column list -154 The create view failed because the view definition contains a union, a union all, or a remote object -156 The statement does not identify a table -157 Only a table name can be specified in a foreign key clause. object-name is not the name of a table. -158 The number of columns specified for the view is not the same as the number of columns specified by the select clause -159 Drop or comment on token identifies a(n) token rather than a(n) token -160 The with check option cannot be used for the specified view -161 The insert or update is not allowed because a resulting row does not satisfy the view definition -164 auth-id1 does not have the privilege to create a view with qualification authorization id -170 The number of arguments specified for function-name is invalid -171 The data type, length, or value of argument nn of function-name is invalid -173 UR is specified on the with clause but the cursor is not read-only -180 The string representation of a datetime value has invalid syntax -181 The string representation of a datetime value is not a valid datetime value -182 An arithmetic expression with a datetime value is invalid -183 An arithmetic operation on a date or timestamp has a result that is not within the valid range of dates -184 An arithmetic expression with a datetime value contains a parameter marker -185 The local format option has been used with a date or time and no local exit has been installed -186 The local date length or local time length has been increased and executing program relies on the old length -187 A reference to a current date/time special register is invalid because the mvs tod clock is bad or the mvs parmtz is out of range -188 The string representation of a name is invalid -189 Ccsid ccsid is unknown or invalid for the data type or subtype -191 A string cannot be used because it is invalid mixed data -197 Qualified column names in order by clause not permitted when union or union all specified -198 The operand of the prepare or execute immediate statement is blank or empty -199 Illegal use of keyword keyword. token token-list was expected -203 A reference to column column-name is ambiguous -204 name is an undefined name -205 column-name is not a column of table table-name -206 column-name is not a column of an inserted table, updated table, or any table identified in a from clause -208 The order by clause is invalid because column name is not part of the result table -198 The operand of the prepare or execute immediate statement is blank or empty -199 Illegal use of keyword keyword. token token-list was expected -203 A reference to column column-name is ambiguous -204 name is an undefined name -205 column-name is not a column of table table-name -206 column-name is not a column of an inserted table, updated table, or any table identified in a from clause -208 The order by clause is invalid because column name is not part of the result table -219 The required explanation table table-name does not exist -220 The column column-name in explanation table table-name is not defined properly -221 “set of optional columns” in explanation table table-name is incomplete. optional column column-name is missing -250 The local location name is not defined when processing a three-part object name -251 Token name is not valid -300 The string contained in host variable or parameter position-number is not nul-terminated -301 The value of input host variable or parameter number position-number cannot be used as specified because of its data type -302 The value of input variable or parameter number position-number is invalid or too large for the target column or the target value -303 A value cannot be assigned to output host variable number position-number because the data types are not comparable -304 A value with data type data-type1 cannot be assigned to a host variable because the value is not within the range of the host variable in position position-number with data type data-type2 -305 The NULL value cannot be assigned to output host variable number position-number because no indicator variable is specified -309 A predicate is invalid because a referenced host variable has the NULL value -310 Decimal host variable or parameter number contains non decimal data. -311 The length of input host variable number position-number is negative or greater than the maximum -312 Undefined or unusable host variable variable-name -313 The number of host variables specified is not equal to the number of parameter markers -314 The statement contains an ambiguous host variable reference -330 A string cannot be used because it cannot be translated. reason reason-code, character code-point, host variable position-number -331 A string cannot be assigned to a host variable because it cannot be translated. reason reason-code, character code-point, position position-number -332 Sysstrings does not define a translation from ccsid ccsid to ccsid -333 The subtype of a string variable is not the same as the subtype known at bind time and the difference cannot be resolved by translation -338 An on clause is invalid -339 The SQL statement cannot be executed from an ascii based drda application requestor to a v2r2 db2 subsystem -351 An unsupported SQLtype was encountered in position “” on a prepare or describe operation -400 The catalog has the maximum number of user defined indexes -401 The operands of an arithmetic or comparison operation are not comparable -402 An arithmetic function or operator arith-fop is applied to character or datetime data -404 The update or insert statement specifies a string that is too long column-name -405 The numeric literal literal cannot be used as specified because it is out of range -406 A calculated or derived numeric value is not within the range of its object column -407 An update or insert value is NULL, but the object column column-name cannot contain NULL values -408 An update or insert value is not comparable with the data type of its object column column-name -409 Invalid operand of a count function -410 The floating point literal literal contains more than 30 characters -411 Current SQLid cannot be used in a statement that references remote objects -412 The select clause of a subquery specifies multiple columns -414 A like predicate is invalid because the first operand is not a string -415 The corresponding columns, column-number, of the operands of a union or a union all do not have comparable column descriptions -416 An operand of a union contains a long string column -417 A statement string to be prepared includes parameter markers as the operands of the same operator -418 A statement string to be prepared contains an invalid use of parameter markers -419 The decimal divide operation is invalid because the result would have a negative scale -420 The value of a character string argument was not acceptable to the function-name function -421 The operands of a union or union all do not have the same number of columns -426 Dynamic commit not valid at an application server where updates are not allowed -427 Dynamic rollback not valid at an application server where updates are not allowed -440 The number of parameters in the parameter list does not match the number of parameters expected for stored procedure name, authid authid, luname luname. number parameters were expected. -444 User program name could not be found -450 Stored procedure name, parameter number number, overlayed storage beyond its declared length -469 SQL call statement must specify an output host variable for parameter number. -470 SQL call statement specified a NULL value for input parameter number, but the stored procedure does not support NULL values -471 SQL call for stored procedure name failed due to reason rc -500 The identified cursor was closed when the connection was destroyed -501 The cursor identified in a fetch or close statement is not open -502 The cursor identified in an open statement is already open -503 A column cannot be updated because it is not identified in the update clause of the select statement of the cursor -504 The cursor name cursor-name is not defined -507 The cursor identified in the update or delete statement is not open -508 The cursor identified in the update or delete statement is not positioned on a row -509 The table identified in the update or delete statement is not the same table designated by the cursor -510 The table designated by the cursor of the update or delete statement cannot be modified -511 The for update clause cannot be specified because the table designated by the cursor cannot be modified -512 Statement reference to remote object is invalid -513 The alias alias-name must not be defined on another local or remote alias -514 The cursor cursor-name is not in a prepared state -516 The describe statement does not identify a prepared statement -517 Cursor cursor-name cannot be used because its statement name does not identify a prepared select statement -518 The execute statement does not identify a valid prepared statement -519 The prepare statement identifies the select statement of the opened cursor cursor-name -525 The SQL statement cannot be executed because it was in error at bind time for section = sectno package = pkgname consistency token = x’contoken’ -530 The insert or update value of foreign key constraint-name is invalid -531 The primary key in a parent row cannot be updated because it has one or more dependent rows in relationship constraint-name -532 The relationship constraint-name restricts the deletion of row with rid x’rid-number’ -533 Invalid multiple-row insert -534 The primary key cannot be updated because of multiple-row update -536 The delete statement is invalid because table table-name can be affected by the operation -537 The primary key clause, a foreign key clause, or a unique clause identifies column column-name more than once -538 Foreign key name does not conform to the description of the primary key of table table-name -539 Table table-name does not have a primary key -540 The definition of table table-name is incomplete because it lacks a primary index or a required unique index -542 column-name cannot be a column of a primary key or a unique constraint because it can contain NULL values -543 A row in a parent table cannot be deleted because the check constraint check-constraint restricts the deletion -544 The check constraint specified in the alter table statement cannot be added because an existing row violates the check constraint -545 The requested operation is not allowed because a row does not satisfy the check constraint check-constraint -546 The check constraint constraint-name is invalid -548 A check constraint that is defined with column-name is invalid -549 The statement statement is not allowed for object_type1 object_name because the bind option dynamicrules(bind) in the object_type2 is in effect -551 auth-id does not have the privilege to perform operation operation on object object-name -552 auth-id does not have the privilege to perform operation operation -553 auth-id specified is not one of the valid authorization ids -554 An authorization id cannot grant a privilege to itself -555 An authorization id cannot revoke a privilege from itself -556 authid2 cannot have the privilege privilege on_object revoked by authid1 because the revokee does not possess the privilege or the revoker did not make the grant -557 Inconsistent grant/revoke keyword keyword. permitted keywords are keyword-list -558 Invalid clause or combination of clauses on a grant or revoke -559 All authorization functions have been disabled -567 bind-type authorization error using auth-id authority package = package-name privilege = privilege -571 The statement would result in a multiple site update -574 The specified default value conflicts with the column definition. -601 The name of the object to be created is identical to the existing name name of the object type obj-type -602 Too many columns specified in a create index -603 A unique index cannot be created because the table contains rows which are duplicates with respect to the values of the identified columns -604 A column definition specifies an invalid length, precision, or scale attribute -607 Operation or option operation is not defined for this object -611 Only lockmax 0 can be specified when the lock size of the tablespace is tablespace or table -612 column-name is a duplicate column name -613 The primary key or a unique constraint is too long or has too many columns -614 The index cannot be created because the sum of the internal lengths of the identified columns is greater than the allowable maximum -615 operation-type is not allowed on a package in use -616 obj-type1 obj-name1 cannot be dropped because it is referenced by obj-type2 obj-name2 -617 A type 1 index cannot be defined on a table in a table space with locksize row -618 Operation operation is not allowed on system databases -619 Operation disallowed because the work file database is not stopped -620 Keyword keyword in stmt type statement is not permitted for a table space in the work file database -621 Duplicate dbid dbid was detected and previously assigned to database-name -622 For mixed data is invalid because the mixed data install option is no -623 A clustering index already exists on table table-name -624 Table table-name already has a primary key -625 Table table-name does not have an index to enforce the uniqueness of the primary key -626 The alter statement is not executable because the page set is not stopped -627 The alter statement is invalid because the pageset has user-managed data sets -628 The clauses are mutually exclusive. -629 Set NULL cannot be specified because foreign key name cannot contain NULL values -630 The where not NULL specification is invalid for type 1 indexes -631 Foreign key name is too long or has too many columns -632 The table cannot be defined as a dependent of table-name because of delete rule restrictions -633 The delete rule must be delete-rule -634 The delete rule must not be cascade -635 The delete rules cannot be different or cannot be set NULL -636 The partitioning keys are not specified in ascending or descending order -637 Duplicate keyword keyword -638 Table table-name cannot be created because column definition is missing -639 A NULLable column of a foreign key with a delete rule of set NULL cannot be a column of the key of a partitioned index -640 Locksize row cannot be specified because table in this tablespace has type 1 index -642 Too many columns in unique constraints -643 Check constraint exceeds maximum allowable length -644 Invalid value specified for keyword keyword in stmt-type tatement -646 Table table-name cannot be created in partitioned/default table space tspace-name because it already contains a table -647 Bufferpool bp-name cannot be specified because it has not been activated -650 The alter index cannot be executed, reason reason -651 Table description exceeds maximum size of object descriptor. -652 Violation of installation defined edit or validation procedure proc-name -653 Table table-name in partitioned table space tspace-name is not available because its partitioned index has not been created -655 The create or alter stogroup is invalid because the storage group would have both specific and non-specific volume ids -660 Index index-name cannot be created on partitioned table space tspace-name because key limits are not specified -661 Index index-name cannot be created on partitioned table space tspace-name because the number of part specifications is not equal to the number of partitions of the table space -662 A partitioned index cannot be created on a non-partitioned table space tspace-name -663 The number of key limit values is either zero, or greater than the number of columns in the key of index index-name -665 The part clause of an alter statement is omitted or invalid -666 stmt-verb object cannot be executed because function is in progress -667 The clustering index for a partitioned table space cannot be explicitly dropped -668 The column cannot be added to the table because the table has an edit procedure -669 A table in a partitioned table space cannot be explicitly dropped -670 The record length of the table exceeds the page size limit -671 The bufferpool attribute of the table space cannot be altered as specified because it would change the page size of the table space -672 Operation drop not allowed on table table_name -676 A 32k page bufferpool may not be used for an index -677 Insufficient virtual storage for bufferpool expansion -678 The literal literal specified for the index limit key must conform to the data type data-type of the corresponding column column-name -679 The object name cannot be created because a drop is pending on the object -680 Too many columns specified for a table -681 Column column-name in violation of installation defined field procedure. rt: return-code, rs: reason-code, msg: message-token -682 Field procedure procedure-name could not be loaded -683 Invalid column type for fieldproc, bit data, sbcs data, or mixed data option, column-name -684 The length of literal list beginning string is too long -685 Invalid field type, column-name -686 Column defined with a field procedure can not compare with another column with different field procedure -687 Field types incomparable -688 Incorrect data returned from field procedure, column-name, msgno -689 Too many columns defined for a dependent table -690 The statement is rejected by data definition control support. reason reason-code -691 The required registration table table-name does not exist -692 The required unique index index-name for ddl registration table table-name does not exist -693 The column column-name in ddl registration table or index table-name (index-name) is not defined properly -694 The ddl statement cannot be executed because a drop is pending on the ddl registration table table-name -713 The replacement value for special-register is invalid -715 Program program-name with mark release-dependency-mark failed because it depends on functions of the release from which fallback has occurred -716 Program program-name precompiled with incorrect level for this release. -717 Bind-type for object-type object-name with mark release-dependency-mark failed because object-type depends on functions of the release from which fallback has occurred. -718 Rebind for package package-name failed because ibmreqd of ibmreqd is invalid -719 Bind add error using auth-id authority package package-name already exists -720 Bind error, attempting to replace package = package_name with version = version2 but this version already exists -721 Bind error for package = pkg-id contoken = ‘contoken’x is not unique so it cannot be created -722 Bind-type error using auth-id authority package package-name does not exist -726 Bind error attempting to replace package = . there are enable or disable entries currently associated with the package -730 The parent of a table in a read-only shared database must also be a table in a read-only shared database -731 User-defined dataset dsname must be defined with shareoptions(1,3) -732 The database is defined on this subsystem with the roshare read attribute but the table space or index space has not been defined on the owning subsystem -733 The description of a table space, index space, or table in a roshare read database must be consistent with its description in the owner system -734 The roshare attribute of a database cannot be altered from roshare read -735 Database dbid cannot be accessed because it is no longer a shared database -736 Invalid obid obid specified -737 Implicit table space not allowed -741 A work file database is already defined for member member-name -742 Dsndb07 is the implicit work file database -751 A stored procedure has been placed in must_rollback state due to SQL operation name -752 The connect statement is invalid because the process is not in the connectable state -802 Exception error ‘exception-type’ has occurred during ‘operation-type’ operation on ‘data-type’ data, position ‘position-number’ -803 An inserted or updated value is invalid because the index in index space indexspace-name constrains columns of the table so no two rows can contain duplicate values in those columns. rid of existing row is x’rid’ -804 An error was found in the application program input parameters for the SQL statement. reason reason -805 Dbrm or package name location-name.collection-id.dbrm-name.consistency -token not found in plan plan-name. reason reason -807 Access denied: package package-name is not enabled for access from connection-type connection-name -808 The connect statement is not consistent with the first connect statement -811 The result of an embedded select statement is a table of more than one row, or the result of the subquery of a basic predicate is more than one value -812 The SQL statement cannot be processed because a blank collection-id was found in the current packageset special register while trying to form a qualified package name for program program-name.consistency-token using plan plan-name -815 A group by or having clause is implicitly or explicitly specified in an embedded select statement or a subquery of a basic predicate -817 The SQL statement cannot be executed because the statement will result in a prohibited update operation -818 The precompiler-generated timestamp x in the load module is different from the bind timestamp y built from the dbrm z -819 The view cannot be processed because the length of its parse tree in the catalog is zero -820 The SQL statement cannot be processed because catalog-table contains a value that is not valid in this release -822 The SQLda contains an invalid data address or indicator variable address -840 Too many items returned in a select or insert list -842 A connection to location-name already exists -843 The set connection or release statement must specify an existing connection -870 The number of host variables in the statement is not equal to the number of descriptors -900 The SQL statement cannot be executed because the application process is not connected to an application server -901 Unsuccessful execution caused by a system error that does not preclude the successful execution of subsequent SQL statements -902 Pointer to the essential control block (ct/rda) has value 0, rebind required -904 Unsuccessful execution caused by an unavailable resource. reason reason-code, type of resource resource-type, and resource name resource-name -905 Unsuccessful execution due to resource limit being exceeded, resource name = resource-name limit = limit-amount1 cpu seconds (limit-amount2 service units) derived from limit-source -906 The SQL statement cannot be executed because this function is disabled due to a prior error -908 Bind-type error using auth-id authority bind, rebind or auto-rebind operation is not allowed -909 The object has been deleted -910 The SQL statement cannot access an object on which a drop or alter is pending -911 The current unit of work has been rolled back due to deadlock or timeout. reason reason-code, type of resource resource-type, and resource name resource-name -913 Unsuccessful execution caused by deadlock or timeout. reason code reason-code, type of resource resource-type, and resource name resource-name -917 Bind package failed -918 The SQL statement cannot be executed because a connection has been lost -919 A rollback operation is required -922 Authorization failure: error-type error. reason reason-code -923 Connection not established: db2 condition reason reason-code, type resource-type, name resource-name -924 Db2 connection internal error, function-code, return-code, reason-code -925 Commit not valid in ims/vs or cics environment -926 Rollback not valid in ims/vs or cics environment -927 The language interface (li) was called when the connecting environment was not established. the program should be invoked under the dsn command -929 Failure in a data capture exit: token -939 Rollback required due to unrequested rollback of a remote server -947 The SQL statement failed because it will change a table defined with data capture changes, but the data cannot be propagated -948 Distributed operation is invalid -950 The location name specified in the connect statement is invalid or not listed in the communications database -965 Stored procedure procname terminated abnormally -2001 The number of host variable parameters for a stored procedure is not equal to the number of expected host variable parameters. actual number SQLdanum, expected number opnum -30000 Execution failed due to a distribution protocol error that will not affect the successful execution of subsequent commands or SQL statements: reason reason-code (sub-code) -30020 Execution failed due to a distribution protocol error that caused deallocation of the conversation: reason -30021 Execution failed due to a distribution protocol error that will affect the successful execution of subsequent commands or SQL statements: manager manager at level level not supported error -30030 Commit request was unsuccessful, a distribution protocol violation has been detected, the conversation has been deallocated. original SQLcode=original-SQLcode and original SQLstate=original-SQLstate -30040 Execution failed due to unavailable resources that will not affect the successful execution of subsequent commands or SQL statements. reason type of resource resource name product id rdbname -30041 Execution failed due to unavailable resources that will affect the successful execution of subsequent commands and SQL statements reason type of resource resource name product id rdbname -30050 command or SQL statement invalid while bind process in progress -30051 Bind process with specified package name and consistency token not active -30052 Program preparation assumptions are incorrect -30053 Owner authorization failure -30060 Rdb authorization failure -30061 Rdb not found -30070 command not supported error -30071 object not supported error -30072 : parameter not supported error -30073 : parameter value not supported error -30074 Reply message with codepoint (svrcod) not supported error -30080 Communication error code (subcode) -30090 Remote operation invalid for application execution environment

Источник

SQLCODE and SQLERRM are Oracle’s built-in error reporting functions in PL/SQL.

When an error occurs in PL/SQL at runtime:

SQLCODE returns the number of the last encountered error.

SQLERRM returns the message associated with its error-number argument. The error-number argument is optional: if omitted, SQLERRM returns the message associated with the current value of SQLCODE.

In this article, we’ll take a look at PL/SQL examples that demonstrate the use of SQLCODE and SQLERRM.

Scenario: SQLCODE and SQLERRM with Internally Defined Exception

Oracle’s internally defined exceptions are standard errors as described in Oracle Database Error Messages Reference. An internally defined exception gets raised implicitly; it always has an error code (of the form ORA-<number>) but does not have an error name unless one is assigned to it in PL/SQL.

When an internally defined exception occurs, SQLCODE returns the numeric value of the associated ORA error. e.g. when the error is ORA-00904, the corresponding SQLCODE is -904 and its SQLERRM is the text of the message associated with ORA-00904.

A typical use case for SQLCODE and SQLERRM is to place them in an OTHERS exception handler.

SQL> -- Scenario: Internally Defined Error
SQL> declare
  2     name emp.ename%type;
  3
  4  begin
  5    -- Incorrect column name
  6    execute immediate
  7    'select namewrong into name
  8    from emp
  9    where rownum = 1';
 10
 11   exception
 12      when others then
 13        dbms_output.put_line('SQLCODE: '|| SQLCODE);
 14        dbms_output.put_line('SQLERRM: '|| SQLERRM);
 15  end;
 16  /
SQLCODE: -904
SQLERRM: ORA-00904: "NAMEWRONG": invalid identifier

PL/SQL procedure successfully completed.

Alternatively, error names can be assigned to internally defined exceptions, and SQLCODE and SQLERRM can be used in exception handlers designed specifically for the error names.

SQL> -- Scenario: Internally Defined Error
SQL> -- with error name explicitly defined
SQL> declare
  2     name emp.ename%type;
  3
  4     -- Assign error name to internally defined error
  5     invalid_column  exception;
  6
  7     -- Associate error name with error code
  8     -- of the internally defined exception
  9     pragma exception_init(invalid_column, -904);
 10  begin
 11    -- Incorrect column name
 12    execute immediate
 13    'select namewrong into name
 14    from emp
 15    where rownum = 1';
 16
 17   exception
 18      -- Named exception handler for ORA-00904
 19      when invalid_column then
 20        dbms_output.put_line('SQLCODE: '|| SQLCODE);
 21        dbms_output.put_line('SQLERRM: '|| SQLERRM);
 22  end;
 23  /
SQLCODE: -904
SQLERRM: ORA-00904: "NAMEWRONG": invalid identifier

PL/SQL procedure successfully completed.

Scenario: SQLCODE and SQLERRM with Predefined Exception

Oracle’s predefined exceptions — such as CASE_NOT_FOUND or ZERO_DIVIDE — are internally defined exceptions with predefined error names.

With predefined exceptions, as with internally defined ones, SQLCODE returns the numeric value of the ORA error associated with the exception. e.g. the ORA error associated with ZERO_DIVIDE is ORA-01476; the corresponding SQLCODE is —1476 and its SQLERRM is the text of the message associated with ORA-01476.

SQLCODE and SQLERRM may be placed either in a named exception handler for the predefined exception name, or in an OTHERS exception handler.

Here’s an example of SQLCODE and SQLERRM in a named exception handler:

SQL> -- Scenario: Predefined Error - ZERO_DIVIDE
SQL> declare
  2     saltransformed emp.sal%type;
  3
  4  begin
  5
  6     -- SQL that returns no data
  7     select sal/0 into saltransformed from emp
  8     where rownum = 1;
  9
 10   exception
 11      when zero_divide then
 12        dbms_output.put_line('SQLCODE: '|| SQLCODE);
 13        dbms_output.put_line('SQLERRM: '|| SQLERRM);
 14  end;
 15  /
SQLCODE: -1476
SQLERRM: ORA-01476: divisor is equal to zero

PL/SQL procedure successfully completed.

Note that the SQLCODE number is negative for all internally defined/predefined exceptions, except for NO_DATA_FOUND whose numeric code is +100.

SQL> -- Scenario: Predefined Error - NO_DATA_FOUND
SQL> declare
  2     name emp.ename%type;
  3
  4  begin
  5
  6     -- SQL that returns no data
  7     select ename into name from emp
  8     where empno = 100;
  9
 10   exception
 11      when no_data_found then
 12        dbms_output.put_line('SQLCODE: ' || SQLCODE);
 13        dbms_output.put_line('SQLERRM: ' || SQLERRM);
 14  end;
 15  /
SQLCODE: 100
SQLERRM: ORA-01403: no data found

PL/SQL procedure successfully completed.

Scenario: SQLCODE and SQLERRM with User-Defined Exception

Oracle’s user-defined exceptions are explicitly defined by the user in PL/SQL, to address the application’s error handling needs beyond internally defined exceptions. For example, while inserting into scott’s emp table, a user-defined exception INVALID_SALARY may be created to validate that emp.sal is more than 0.

A user-defined exception must be raised explicitly in code; it always has an error name, but does not have an error code unless assigned.

For a user-defined exception, the default value of SQLCODE is +1 and of SQLERRM is «User-Defined Exception».

SQL> -- Scenario: User-Defined Error
SQL> -- with error code not defined
SQL> declare
  2     sal emp.sal%type;
  3
  4     -- Assign error name to user-defined error
  5     invalid_salary  exception;
  6
  7  begin
  8    -- SQL to select invalid value
  9    select 0 into sal
 10    from emp
 11    where rownum = 1;
 12
 13    -- Raise user-defined error
 14    if sal <= 0 then
 15      raise invalid_salary;
 16    end if;
 17
 18   exception
 19      -- Named exception handler for user-defined error
 20      when invalid_salary then
 21        dbms_output.put_line('SQLCODE: '|| SQLCODE);
 22        dbms_output.put_line('SQLERRM: '|| SQLERRM);
 23  end;
 24  /
SQLCODE: 1
SQLERRM: User-Defined Exception

PL/SQL procedure successfully completed.

The default values of SQLCODE and SQLERRM in case of user-defined exceptions are typically overriden to give them more specific/meaningful values.

SQLCODE is overriden with EXCEPTION_INIT pragma. The error number should be a negative integer in the range -20000 to —20999.
SQLERRM is overriden with RAISE_APPLICATION_ERROR. The error message should be a string up to 2048 bytes long.

SQL> -- Scenario: User-Defined Error
SQL> -- with error code/message explicitly defined
SQL> declare
  2     sal emp.sal%type;
  3
  4     -- Assign error name to user-defined error
  5     invalid_salary  exception;
  6
  7     -- Assign error code to user-defined error
  8     -- and associate it with the error name
  9     pragma exception_init(invalid_salary, -20000);
 10
 11  begin
 12    -- SQL to select invalid value
 13    select 0 into sal
 14    from emp
 15    where rownum = 1;
 16
 17    -- Raise user-defined error with custom message
 18    if sal <= 0 then
 19      raise_application_error(-20000
 20                  , 'Salary must be more than zero');
 21    end if;
 22
 23   exception
 24      -- Named exception handler for user-defined error
 25      when invalid_salary then
 26        dbms_output.put_line('SQLCODE: '|| SQLCODE);
 27        dbms_output.put_line('SQLERRM: '|| SQLERRM);
 28  end;
 29  /
SQLCODE: -20000
SQLERRM: ORA-20000: Salary must be more than zero

PL/SQL procedure successfully completed.

How do SQLCODE and SQLERRM behave outside an exception handler?

SQLCODE and SQLERRM are mainly useful in an exception handler.

Outside an exception handler:

SQLCODE returns 0
SQLERRM (without argument) returns the message normal, successful completion.

SQL> -- Scenario: No error
SQL> declare
  2     name emp.ename%type;
  3
  4  begin
  5
  6     -- Valid SQL
  7     select ename into name from emp
  8     where rownum = 1;
  9
 10     dbms_output.put_line('Name: '|| name);
 11
 12     -- SQLCODE and SQLERRM values when no error
 13     dbms_output.put_line('SQLCODE: '|| SQLCODE);
 14     dbms_output.put_line('SQLERRM: '|| SQLERRM);
 15  end;
 16  /
Name: KING
SQLCODE: 0
SQLERRM: ORA-0000: normal, successful completion

PL/SQL procedure successfully completed.

SQLERRM with error-number argument

The default value of SQLERRM – i.e. the message associated with the current value of SQLCODE – can be overridden by giving it an error number as argument. Let’s try that with the previous no-error example with a small tweak: change the last dbms_output.put_line to print SQLERRM with argument.

SQL> -- Scenario: No error, SQLERRM with argument
SQL> declare
  2     name emp.ename%type;
  3
  4  begin
  5
  6     -- Valid SQL
  7     select ename into name from emp
  8     where rownum = 1;
  9
 10     dbms_output.put_line('Name: '|| name);
 11
 12     -- SQLCODE and SQLERRM values when no error
 13     dbms_output.put_line('SQLCODE: '|| SQLCODE);
 14     dbms_output.put_line('SQLERRM(-42): '|| SQLERRM(-42));
 15  end;
 16  /
Name: KING
SQLCODE: 0
SQLERRM(-42): ORA-00042: Unknown Service name

PL/SQL procedure successfully completed.

…which shows that SQLERRM prints the message associated with its argument, instead of the message associated with SQLCODE.

What is the maximum length of SQLERRM?

We may need to know the maximum length of SQLERRM for various reasons e.g. while designing an EXCEPTIONS table to log application errors, or while creating a PL/SQL string variable to hold its value.

Oracle documentation has this to say about SQLERRM:

This function returns a maximum of 512 bytes, which is the maximum length of an Oracle Database error message (including the error code, nested messages, and message inserts such as table and column names).

Interestingly, this script by Matt Mulvaney tests the length assertion, and finds that the actual maximum length of SQLERRM is a bit less!

Summary

This article describes Oracle functions SQLCODE and SQLERRM and shows examples of their use with:

internally defined exceptions
predefined exceptions
user-defined exceptions
no exceptions

Источник

PL/SQL блок:

DECLARE
… — объявляющая секция
BEGIN
… — выполняющая секция
EXCEPTION
… — секция обработки исключительных ситуаций
END;
/

При установлении исключительной ситуации управление программой сразу же передается
в секцию исключительных ситуаций блока.
Если такой секции в блоке нет, то исключение передается в объемлющий блок.

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

Исключения бывают:

— стандартные
— определенные пользователем

Стандартные исключительные ситуации инициируются автоматически при возникновении
соответствующей ошибки Oracle.

Исключительные ситуации, определяемые пользователем,
устанавливаются явно при помощи оператора RAISE.

Обрабатываются исключения так:

EXCEPTION
    WHEN имя_ex1 THEN
        …; — обработать
    WHEN имя_ex2 THEN
        …; — обработать
    WHEN OTHERS THEN
        …; — обработать
END;
/

Имена исключений не должны повторяться т.е. каждое исключение может
обрабатываться максимум только одним обработчиком в секции EXCEPTION

Один обработчик может обслуживать несколько исключительных ситуаций
и их нужно перечислить в условии WHEN через OR

EXCEPTION
WHEN NO_DATA_FOUND OR TOO_MANY_ROWS THEN
INSERT INTO log_table(info) VALUES (‘A select error occurred.’);
END;
/

Два исключения одновременно один обработчик обработать не может:

WHEN имя_ex1 AND имя_ex2 — > ERR

Пользовательское исключение должно быть определено:

DECLARE
    e_my_ex EXCEPTION;
    …
BEGIN
    IF (…) THEN
        RAISE e_my_ex;
    END IF;
    …

EXCEPTION
WHEN e_my_ex THEN
…
END;
/

После перехвата более специализированных исключений:

WHEN … THEN
…
WHEN … THEN

мы можем перехватить все остальные исключения с помощью:

WHEN OTHERS THEN
…

Обработчик OTHERS рекомендуется помещать на самом высоком уровне программы:
(В самом высшем блоке)
для обеспечения распознавания всех возможных ошибок.

Иначе ошибки будут распространяться в вызывающую среду и возможны
нежелательные последствия, такие как откат на сервере текущей транзакции.

Не используйте в промышленном коде такое:

WHEN OTHERS THEN NULL;

т.к. оно будет молчаливо перехватывать все неожиданные ошибки не сообщая,
что они произошли.

Обработчик OTHERS должен регистрировать ошибку и возможно предоставлять
дополнительную информацию для дальнейшего исследования.

WHEN OTHERS THEN
INSERT INTO log_table(info) VALUES (‘Another error occurred.’);
END;
/

Информацию об ошибках можно получить при помощи двух встроенных функций:

— SQLCODE
— SQLERRM

первая возвращает код текущей ошибки а вторая текст сообщения об ошибке

Для исключений определенных пользователем:

SQLCODE возвращает 1
а
SQLERRM «User-defined Exception»

WHEN OTHERS THEN
    v_ErrorCode := SQLCODE;
    v_ErrorText := SUBSTR(SQLERRM, 1, 200);
    INSERT INTO log_tab(code, message, info) VALUES (v_ErrorCode, v_ErrorText, ‘Oracle error.’);
END;
/

В таблице log_tab поле message ограничено 200 символами
и чтобы не произошло ошибки при вставке, мы урезаем длину
сообщения до 200 символов с помощью SUBSTR
А то максимальная длина сообщения может достигать 512 символов.

Функция SQLERRM может принимать один числовой аргумент.
При этом она возвратит текст сообщения об ошибке, код которой равен заданному числу.

Аргумент должен быть всегда отрицательным числом.
Если аргумент равен 0, то будет возвращено сообщение:
ORA-0000: normal, succesful completion

При положительном аргументе не равном 100 будет возвращено сообщение:
non-ORACLE Exception

А при

SQLERRM(100) — > ORA-1403: no data found

Это исключение ANSI

Остальные коды ошибок Oracle все отрицательные.

Для получения информации об ошибке можно также использовать функцию
FORMAT_ERROR_STACK из пакета DBMS_UTILITY

Её можно непосредственно использовать в операторах SQL:

WHEN OTHERS THEN
    INSERT INTO log_tab(code, message, info) VALUES (NULL,
                                                     SUBSTR(DBMS_UTILITY.FORMAT_ERROR_STACK, 1, 200),
                                                    ‘Oracle error occurred.’);
END;
/

Ещё одна функция.

DBMS_UTILITY.FORMAT_ERROR_BACKTRACE

она аналогична FORMAT_ERROR_STACK
но не подвержена ограничению длины сообщения в 2000 байт.
Она возвращает полностью весь стек ошибок на момент инициирования исключительной ситуации.

Любое именованное исключение можно связать с конкретной ошибкой ORACLE.

Например, в ORACLE есть стандартная ошибка ORA-1400, которая возникает при пропуске значения
или вставке значения NULL в столбец с ограничением NOT NULL.

ORA-1400: mandatory NOT NULL column missing or NULL during insert.

Мы хотим создать свое пользовательское именованное исключение и связать его с этой стандартной ошибкой ORA-1400

DECLARE
e_my_ex EXCEPTION;
PRAGMA EXCEPTION_INIT(e_my_ex, -1400);

BEGIN
WHEN e_my_ex THEN
INSERT INTO log_tab(info) VALUES (‘ORA-1400 occurred.’);
END;
/

Теперь мы перехватываем её по имени с помощъю WHEN или THEN

Все стандартные исключительные ситуации также ассоциируются с соответствующими им ошибками Oracle
при помощи прагмы EXCEPTION_INIT в пакете STANDARD

VALUE_ERROR — > ORA-6501
TO_MANY_ROWS — > ORA-1422
ZERO_DIVIDE — > ORA-1476
……….
и т.д.

Так что если вам не хватает некоего имени конкретной ошибки ORA-NNNN,
то придумайте свое имя и свяжите его с ошибкой с помощью прагмы : EXCEPTION_INIT

Для собственных пользовательских исключений можно придумать свои коды ошибок, которые разрешено брать из диапазона:
-20000 до -20999
и придумать свой текст сообщения

RAISE_APPLICATION_ERROR(номер, текст, [флаг]);

TRUE — пополнить список ранее произошедших ошибок
FALSE — новая ошибка заместит текущий список ошибок (по умолчанию)

set serveroutput on

variable a NUMBER;
variable b NUMBER;

exec :a := 0;
exec :b := 10;

DECLARE
    l_a NUMBER := :a;
    l_b NUMBER := :b;
    l_c NUMBER;

BEGIN
    IF l_a = 0 THEN
        raise_application_error(-20005, ‘Divizor is 0’);
    END IF;
    l_c := l_b / l_a;
    dbms_output.put_line(‘The result: ‘||l_c);
EXCEPTION
    WHEN OTHERS THEN
        dbms_output.put_line(SQLERRM);
END;
/

Поскольку у исключения нет имени, то его может обработать только обработчик OTHERS

Но такое исключение можно и поименовать
и с помощью прагмы связать с нашим кодом.

DECLARE

    my_ex EXCEPTION;
    …..
    …..
    PRAGMA EXCEPTION_INIT(my_ex, -20005);

BEGIN
    IF (…) THEN
        raise_application_error(-20005, ‘Divizor is 0’);
    …..
    …..

EXCEPTION
WHEN my_ex THEN
dbms_output.put_line(SQLERRM);
END;
/

Теперь это исключение можно обработать по имени с помощью:

WHEN my_ex THEN

EXCEPTION PROPAGATION

enclosing block — обьемлющий блок

Если в текущем блоке имеется обработчик данной исключительной ситуации,
то он выполняется и блок успешно завершается.
Управление передаётся вышестоящему блоку.

Если обработчик отсутствует, исключительная ситуация передается в обьемлющий блок и инициируется там.
Если обьемлющего блока не существует, то исключение будет передано вызывающей среды (например SQL*Plus).

При вызове процедуры также может создаваться обьемлющий блок:

BEGIN

    p(…); — вызов процедуры
EXCEPTION
    WHEN OTHERS THEN
        — исключение инициированное p()
        — будет обработано здесь
END;
/

Исключения инициируемые в секции обьявлений (DECLARE) не обрабатываются секцией EXCEPTION
текущего блока, а передаются в EXCEPTION обьемлющего блока.

Тоже самое, если исключение инициируется в секции EXCEPTION,
то обработка данного исключения передается в обьемлющий блок.

Исключительную ситуацию можно обработать в текущем блоке и сразу снова установить
то же самое исключение, которое будет передано в обьемлющую область:

DECLARE

A EXCEPTION;
BEGIN

    RAISE A;
EXCEPTION
    WHEN A THEN
        INSERT INTO log_tab(info) VALUES (‘Exception A occurred.’);
        COMMIT;
        RAISE;
END;
/

Тут commit гарантирует, что результаты insert будут зафиксированы
в базе данных в случае отката транзакции.

С помощью пакета UTL_FILE можно избежать необходимости commit
или используйте автономные транзакции.

Область действия исключительной ситуации

BEGIN
    DECLARE
        e_ex EXCEPTION; — видно по имени только внутри блока
    BEGIN
        RAISE e_ex;
    END;
EXCEPTION
    — тут исключение не видно по имени e_ex
    — и его можно обработать с помощью обработчика OTHERS

    WHEN OTHERS THEN
        — инициируем это исключение повторно
        RAISE; — Теперь это исключение передается вызывающей среде
END;
/

Если сообщение об ошибке, определяемой пользователем, нужно передать из блока,
рекомендуется описывать исключительную ситуацию и модуле так,
чтобы она была видима вне этого блока.
Или воспользуйтесь функцией : RAISE_APPLICATION_ERROR

Как описать исключение, которое будет видно вне блока?

Нужно создать пакет Globals и описать в нем пользовательское исключение.
Такая исключительная ситуация будет видима и во внешнем блоке.

CREATE OR REPLACE PACKAGE Globals AS
e_ex EXCEPTION;
END Globals;

BEGIN
    BEGIN
        RAISE Globals.e_ex;
    END;

EXCEPTION
    WHEN Globals.e_ex THEN
        — инициируем повторно
        — для передачи в вызывающую среду
        RAISE;
END;
/

В пакете Globals можно также объявлять:

— таблицы
— переменные
— типы

Избегайте необработанных исключений
Нельзя допускать завершение программ, пока в них остаются необработанные исключения

Используйте обработчик OTHERS на самом верхнем уровне программы.
И пусть он регистрирует факт и время возникновения ошибки.
И ни одна ошибка не останется без внимания.

DECLARE

    v_ErrorNumber NUMBER;
    v_ErrorText   VARCHAR2(200);
BEGIN
    …
    …

EXCEPTION
WHEN OTHERS THEN
…

v_ErrorNumber := SQLCODE;
v_ErrorText := SUBSTR(SQLERRM, 1, 200);

        INSERT INTO log_tab(code, message, info)
        VALUES (v_ErrorNumber, v_ErrorText,
                ‘Oracle error …at ‘ || to_char(sysdate, ‘DD-MON-YYHH24:MI:SS’));
END;
/

Можно использовать и утилиту DBMS_UTILITY.FORMAT_ERROR_BACKTRACE
она регистрирует первоначальное местовозникновения исключения.

Как определить, где произошла ошибка?

BEGIN

    SELECT …
    SELECT …
    SELECT …
EXCEPTION
    WHEN NO_DATA_FOUND THEN
    — какой select инициировал ошибку?
END;
/

Можно создать счетчик, указывающий на sql — оператор:

DECLARE

v_sel_count NUMBER := 1;
BEGIN

    SELECT …
    v_sel_count := 2;
    SELECT …
    v_sel_count := 3;
    SELECT …

EXCEPTION
    WHEN NO_DATA_FOUND THEN
        INSERT INTO log_tab(info)
        VALUES (‘no data found in select ‘||v_sel_count);
END;
/

Можно разместить каждый select в собственном врутреннем блоке

BEGIN

    BEGIN
        SELECT …
    EXCEPTION
        WHEN NO_DATA_FOUND THEN
            INSERT INTO log_tab(info)
            VALUES (‘no data found in select 1’);
    END;

    BEGIN
        SELECT …
    EXCEPTION
        WHEN NO_DATA_FOUND THEN
            INSERT INTO log_tab(info)
            VALUES (‘no data found in select 2’);
    END;

    BEGIN
        SELECT …
    EXCEPTION
        WHEN NO_DATA_FOUND THEN
            INSERT INTO log_tab(info)
            VALUES (‘no data found in select 3’);
    END;

END;
/

Или использовать : DBMS_UTILITY.FORMAT_ERROR_BACKTRACE
и потом анализировать файл трассировки.

Пусть в нашей программе Oracle выдает ошибку ORA-01844: not f valid month

перехватить его можно так:

EXCEPTION
WHEN OTHERS THEN
IF SQLCODE = -1843 THEN

Да, код плохо читаем.
Сделаем его более лучшим:

PROCEDURE my_procedure
IS
invalid_month EXCEPTION;
PRAGMA EXCEPTION_INIT(invalid_month, -1843);

BEGIN
….
EXCEPTION
WHEN invalid_month THEN

так уже более понятней.

Источник

Как отлавливать ошибки в Oracle (PLSQL) EXCEPTION,SQLERRM,SQLCODE

Осваиваем Oracle и PL/SQL

Маленькое руководство по отлавливанию ошибок в Oracle PLSQL.
Описание как использовать в Oracle (PLSQL) функции SQLERRM и SQLCODE для отлова ошибок EXCEPTION, с описанием синтаксиса и примером.

Функция SQLERRM возвращает сообщение об ошибке связанное с последним возникшим исключением (ошибкой).
Функция SQLERRM — не имеет параметров.

Функция SQLCODE возвращает код ошибки связанный с последним возникшим исключением (ошибкой)
Функция SQLERRM — не имеет параметров.

Обычно обработка исключений EXCEPTION выглядит следующим образом:

EXCEPTION
   WHEN наименование_ошибки_1 THEN
      [statements]

   WHEN наименование_ошибки_2 THEN
      [statements]

   WHEN наименование_ошибки_N THEN
      [statements]

   WHEN OTHERS THEN
      [statements]

END [наименование_процедуры];

Вы можете использовать функции SQLERRM и SQLCODE для вызова сообщения об ошибке например таким образом:

EXCEPTION
   WHEN OTHERS THEN
      raise_application_error(-20001,'Произошла ошибка - '||SQLCODE||' -ERROR- '||SQLERRM);
END;
-- В данном случае появится всплывающее сообщение.

Или вы можете сохранить сообщение об ошибке в таблицу таким образом:

EXCEPTION
   WHEN OTHERS THEN
      err_code := SQLCODE;
      err_msg := SUBSTR(SQLERRM, 1, 200);

      INSERT INTO error_log_table (error_time, error_number, error_message)
      VALUES (sysdate, err_code, err_msg);
END;
--В данном случае ошибка будет помещена в таблицу error_log_table

Варианты основных возможных ошибок:

DUP_VAL_ON_INDEX
ORA-00001
При попытке произвести вставку INSERT или изменение UPDATE данных которое создает дублирующую запись нарушающую уникальный индекс (unique index).

TIMEOUT_ON_RESOURCE
ORA-00051
Происходит когда ресурс над которым производится операция заблокирован и произошел сброс по таймауту.

TRANSACTION_BACKED_OUT
ORA-00061
Произошёл частичный откат транзакции.

INVALID_CURSOR
ORA-01001
Попытка использовать курсор которого не существует. Может происходить если вы пытаетесь использовать FETCH курсор или закрыть CLOSE курсор до того как вы этот курсор открыли OPEN.

NOT_LOGGED_ON
ORA-01012
Попытка произвести действия не залогинившись.

LOGIN_DENIED
ORA-01017
Неудачная попытка залогиниться, в доступе отказано, не верный пользователь или пароль.

NO_DATA_FOUND
ORA-01403
Что то из перечисленного: Попытка произвести вставку SELECT INTO несуществующего набора значений (select — ничего не возвращает). Попытка доступа к неинициализированной строке/записи в таблице. Попытка чтения записи после окончания файла при помощи пакета UTL_FILE.

TOO_MANY_ROWS
ORA-01422
Попытка вставить значение в переменную при помощи SELECT INTO и select вернул более чем одно значение.

ZERO_DIVIDE
ORA-01476
Попытка деления на ноль.

INVALID_NUMBER
ORA-01722
Попытка выполнить SQL запрос который производит конвертацию строки (STRING) в число (NUMBER) при этом такое преобразование невозможно.

STORAGE_ERROR
ORA-06500
Либо нехватка памяти, либо ошибка в памяти.

PROGRAM_ERROR
ORA-06501
Внутренняя программная ошибка рекомендуется с такой ошибкой обращаться в службу поддержки Oracle.

VALUE_ERROR
ORA-06502
Попытка выполнить операцию конвертации данных которая закончилась с ошибкой (например: округление, преобразование типов, и т.п.).

CURSOR_ALREADY_OPEN
ORA-06511
Вы пытаетесь открыть курсор который уже открыт.

Вот пожалуй и всё.

Oracle
PLSQL
SQL
EXCEPTION
SQLERRM
SQLCODE
ошибки
программирование

Источник

Основные концепции и терминология обработки исключений

Определение исключений

Объявление именованных исключений

Связывание имени исключения с кодом ошибки

Директива EXCEPTION_INIT

Рекомендации по использованию EXCEPTION_INIT

Именованные системные исключения

Область действия исключения

Инициирование исключений

Команда RAISE

Процедура RAISE_APPLICATION_ERROR

Обработка исключений

Встроенные функции ошибок

Подробнее о DBMS_UTILITY.FORMAT_ERROR_BACKTRACE

Только номер строки, пожалуйста

Полезные применения SQLERRM

Объединение нескольких исключений в одном обработчике

Необработанные исключения

Передача необработанного исключения

Потеря информации об исключении

Примеры передачи исключения

Продолжение выполнения после исключений

Написание раздела WHEN OTHERS

Построение эффективной архитектуры управления ошибками

Определение стратегии управления ошибками

Стандартизация обработки разных типов исключений

Преднамеренные исключения

Нежелательные и непредвиденные исключения

Как извлечь пользу из этой классификации

Коды ошибок, связанные с конкретным приложением

Стандартизация обработки ошибок

Работа с «объектами» исключений

Создание стандартного шаблона для обобщенной обработки ошибок

Оптимальная организация обработки ошибок в PL/SQL

Вас заинтересует / Intresting for you:

Scenario: SQLCODE and SQLERRM with Internally Defined Exception

Scenario: SQLCODE and SQLERRM with Predefined Exception

Scenario: SQLCODE and SQLERRM with User-Defined Exception

How do SQLCODE and SQLERRM behave outside an exception handler?

SQLERRM with error-number argument

What is the maximum length of SQLERRM?

Summary

EXCEPTION PROPAGATION

Как отлавливать ошибки в Oracle (PLSQL) EXCEPTION,SQLERRM,SQLCODE