Запросы при работе с классом EXCEPTIONS

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

exception: INTEGER

-- Код последнего встретившегося исключения

original_exception: INTEGER

-- Код последнего исключения - первопричины текущего исключения

Разница между exception и original_exception важна в случае " организованной паники". Если программа получила исключение с кодом oc, указывающим на арифметическое переполнение, но не имеет предложения rescue, то вызывающая программа получит исключение, код которого, заданный значением exception, будет указывать на " отказ в вызванной программе". Но на этом этапе или выше по цепи вызовов может понадобиться выяснить оригинальное исключение - первопричину появления исключений - код oc, который и будет значением original_exception.

Коды исключений являются целыми. Значения для предопределенных исключений задаются целочисленными константами, обеспечиваемыми классом EXCEPTIONS (который наследует их от класса EXCEPTIONS_CONSTANTS). Вот несколько примеров:

Check_instruction: INTEGER is 7

-- Код исключения при нарушении утверждения check

Class_invariant: INTEGER is...

-- Код исключения при нарушении инварианта класса

Incorrect_inspect_value: INTEGER is...

-- Код исключения, когда проверяемое значение не является ни одной

-- ожидаемых констант, если отсутствует часть Else

Loop_invariant: INTEGER is...

-- Код исключения при нарушении инварианта цикла

Loop_variant: INTEGER is...

-- Код исключения при нарушении убывания варианта цикла

No_more_memory: INTEGER is...

-- Код исключения при отказе в распределении памяти

Postcondition: INTEGER is...

-- Код исключения при нарушении постусловия

Precondition: INTEGER is...

-- Код исключения при нарушении предусловия

Routine_failure: INTEGER is...

-- Код исключения при отказе вызванной программы

Void_assigned_to_expanded: INTEGER is...

Так как значения констант не играют здесь роли, то показано только первое из них.

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

meaning (except: INTEGER)

-- Сообщение, описывающее природу исключения с кодом except

is_assertion_violation: BOOLEAN

-- Является ли последнее исключение нарушением утверждения

-- или нарушением убывания варианта цикла

ensure

Result = (exception = Precondition) or (exception = Postcondition) or

(exception = Class_invariant) or

(exception = Loop_invariant) or (exception = Loop_variant)

is_system_exception: BOOLEAN

-- Является ли последнее исключение внешним событием

-- (ошибкой операционной системы)?

is_signal: BOOLEAN

-- Является ли последнее исключение сигналом операционной системы?

tag_name: STRING

-- Метка утверждения, нарушение которого привело к исключению

original_tag_name: STRING

-- Метка последнего нарушенного утверждения оригинальным исключением.

recipient_name: STRING

-- Имя программы, чье выполнение было прервано последним исключением

class_name: STRING

-- Имя класса, включающего получателя последнего исключения

original_recipient_name: STRING

-- Имя программы, чье выполнение было прервано

-- последним оригинальным исключением

original_class_name: STRING

-- Имя класса, включающего получателя последнего оригинального исключения

Имея эти свойства, предложение rescue может управлять каждым исключением особым способом. Например, в классе, наследуемом от EXCEPTIONS, предложение rescue можно написать так:

rescue

if is_assertion_violation then

" Случай, обрабатывающий нарушение утверждений"

else if is_signal then

" Случай, обрабатывающий сигналы операционной системы"

else

...

end

Используя класс EXCEPTIONS, можно модифицировать пример quasi_inverse, чтобы он выполнял retry только при переполнении. Другие исключения, например, нажатие пользователем клавиши " break" не должны приводить к retry. Инструкция в предложении rescue теперь может иметь вид:

if exception = Numerical_error then

division_tried: = True; retry

end

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

Какой должна быть степень контроля?

Могут возникнуть замечания по поводу уровня обработки специфических исключений, иллюстрируемых двумя последними примерами. В этой лекции проводилась та точка зрения, что исключение - нежелательное событие; когда оно возникает, то естественная реакция ПО и его разработчика - " я не хочу быть здесь! Выпустите меня отсюда, как можно скорее! ". Это, кажется, несовместимым с проведением в предложении rescue глубокого анализа источника исключений.

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

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