Случаи, в которых используются исключения
В разделе «Мертвые программы не лгут» высказано предложение считать хорошим тоном проверку всех возможных ошибок, в особенности возникающих неожиданно. Однако на практике это может привести к тому, что программа станет уродливой; нормальная логика вашей программы может сойти на нет из-за ее затуманивания процедурами обработки ошибок, особенно если вы являетесь приверженцем школы программирования, девиз которой звучит так: «В подпрограмме должен иметься один-единственный оператор return» (авторы не являются приверженцами указанной школы). Нам приходилось видеть текст программы, выглядевший следующим образом:
retcode = OK;
if (socket.read(name)!=OK) {
retcode = BAD_READ;
}
else
processName(name);
if (socket.read(address)!=OK) {
retcode = BAD READ;
}
else {
processAddress(address);
if (socket.read(telNo)!= OK) {
retcode= BAD_READ
}
else {
// etc, etc…
}
}
}
return retcode;
Но если язык программирования (no счастливой случайности) поддерживает исключения, то эту программу можно написать намного изящнее:
retcode = OK;
try {
socket.read(name);
process(name);
socket.read(address);
processAddress(address);
socket.read(telNo);
// etc, etc…
}
catch (lOException e) {
retcode = BAD_READ;
Logger.log("Error reading individual;» +e.getMessage());
}
return retcode;
Теперь схема управления отличается ясностью – вся обработка ошибок сосредоточена в одном-единственном месте.
Что является исключительным?
Одна из проблем, связанных с исключениями, заключается в том, что необходимо знать, когда их можно использовать. Мы полагаем, что не стоит злоупотреблять исключениями для нормального хода выполнения программы; они должны быть зарезервированы для нештатных ситуаций. Предположите, что неперехваченное исключение прекратит работу вашей программы, и спросите себя: «А будет ли эта программа исполняться, если удалить все обработчики исключений?». Если ответ отрицательный, то вполне возможно, что исключения используются в обстоятельствах, их не требующих.
Например, если ваша программа пытается открыть файл для чтения, а этот файл не существует, нужно ли возбуждать исключение?
Мы отвечаем следующим образом: «Это зависит от конкретного случая». Если файл должен был там находиться, то исключение гарантировано. Произошло что-то непредвиденное – файл, который вы считали существующим, похоже, исчез. С другой стороны, если вы понятия не имеете, должен ли этот файл существовать или нет, то его отсутствие уже не кажется столь исключительным и возвращение ошибки вполне уместно.
Рассмотрим пример с первой ситуацией. Представленная ниже программа открывает файл /etc/passwd, который обязан существовать во всех системах Unix. Если файл не открывается, происходит передача исключения FileNotFoundException к вызывающей программе.
public void open_passwd() throws FileNotFoundException {
//При этом может возбуждаться FileNotFoundException…
ipstream = new FilelnputStream("/efc/passwd»);
//…
}
Однако во второй ситуации может происходить открытие файла, указанного пользователем в командной строке. Здесь возбуждение исключения не гарантируется, и программа выглядит по-другому:
public boolean open_user_file(String name)
throws FileNotFoundException {
File f = new File(name);
if (!f.exists()) {
return false;
}
ipstream = new FilelnputStream(f);
return true;
}
Обратите внимание на то, что вызов FilelnputStream все еще способен генерировать исключение, передаваемое подпрограммой. Но при этом исключение будет сгенерировано лишь в действительно исключительных обстоятельствах; простая попытка открыть несуществующий файл сгенерирует обычное возвращение ошибки.
Подсказка 34: Пользуйтесь исключениями только в исключительных случаях
Почему мы предлагаем именно такой подход к исключениям? Конечно, исключение представляет собой мгновенную нелокальную передачу управления – своего рода многоуровневый оператор goto. Программы, использующие исключения в своей обычной работе, испытывают те же проблемы с удобочитаемостью и сопровождением, которые свойственны классическим неструктурированным программам. Эти программы нарушают инкапсуляцию: подпрограммы и их вызывающие программы отличаются более сильной связанностью за счет обработки исключений.
Обработчики ошибок как альтернатива исключению
Обработчик ошибок представляет собой подпрограмму, которая вызывается при обнаружении ошибки. Вы можете зарегистрировать подпрограмму для обработки определенной категории ошибок. При возникновении одной из этих ошибок происходит вызов обработчика.
Возникают ситуации, когда вам захочется применить обработчики ошибок вместо исключений или же одновременно с ними. Понятно, что, если вы работаете с языком С, не поддерживающим исключения, это один из нескольких возможных вариантов (см. Вопрос для обсуждения ниже). Но иногда обработчики ошибки могут использоваться даже в языках (типа Java), обладающих хорошей встроенной схемой обработки исключений.
Рассмотрим реализацию приложения «клиент-сервер» с использованием средства RMI (удаленный вызов метода) в языке Java. Поскольку RMI реализован определенным способом, каждое обращение к удаленной подпрограмме должно быть подготовлено, с тем чтобы обработать ситуацию RemoteException. Добавление программы обработки этих исключений может представлять собой утомительную процедуру и означает сложность написания программы, которая могла бы работать как с локальными, так и с удаленными подпрограммами. Обойти эту трудность возможно путем инкапсулирования удаленных объектов в класс, не являющийся удаленным. Тогда этот класс сможет реализовать интерфейс обработчика ошибок, позволяя программе клиента регистрировать подпрограмму, обращение к. которой происходит при обнаружении удаленной исключительной ситуации.
• Мертвые программы не лгут
• В языках программирования, не поддерживающих исключительные ситуации, часто используется иной (нелокальный) способ передачи механизма управления (например, в языке С существует средство longjmp/setjmp). Подумайте, как можно реализовать некий «суррогатный» механизм исключения, используя указанные средства. В чем состоят преимущества и опасности? Какие специальные меры необходимо предпринять для гарантии того, что эти ресурсы не «осиротеют»? Есть ли смысл использовать подобное решение всякий раз, когда вы пишете программу на языке С?
21. При проектировании нового класса контейнера имеются три возможных состояния ошибки:
1. Не хватает памяти для нового элемента в подпрограмме add.
2. В подпрограмме fetch не обнаружена запрашиваемая точка входа.
3. Указатель null передан к подпрограмме add.
Каким образом необходимо обрабатывать каждую из этих ошибок? Нужна ли генерация ошибки, возбуждение исключительной ситуации, или же это состояние должно игнорироваться? (Ответ см. в Приложении В).
25Балансировка ресурсов
«Я привел тебя в этот мир», – сказал бы мой отец, – «я же могу и отправить тебя обратно. Мне это без разницы. Я сделаю еще одного такого, как ты».
При написании программ всем нам приходится управлять ресурсами: памятью, транзакциями, потоками, файлами, таймерами – словом, всеми типами объектов, доступность которых ограничена. Большую часть времени использование ресурса следует предсказуемой схеме: ресурс назначается, используется, а затем освобождается.
Однако многие разработчики не имеют сколько-нибудь завершенного плана, касающегося распределения и освобождения ресурсов. Поэтому предлагается простая подсказка:
Подсказка 35: Доводите до конца то, что начинаете
В большинстве случаев эту подсказку применить несложно. Она всего лишь означает, что подпрограмма или объект, который назначает ресурс, должен нести ответственность за освобождение этого ресурса. Использование указанной подсказки можно рассмотреть на примере неудачной программы – приложения, открывающего файл, считывающего из него информацию о заказчике, обновляющего поле и записывающего результат обратно в файл. Чтобы сделать пример более наглядным, мы опустили процедуру обработки ошибок.
void readCustomer(const char *fName, Customer *cRec) {
cFiie = fopen(fName, «r+»);
fread(cRec, sizeof(*cRec), 1, cFile);
}
void writeCustomer(Customer *cRec) {
rewind(cFile);
fwrite(cRec, sizeof(*cRec), 1; cFile);
fclose(cFile);
}
void updateCustomer(const char *fName, double newBalance) {
Customer cRec;
readCustomer(fName, &cRec);
cRec.balance = newBalance;
writeCustomer(&cRec);
}
На первый взгляд, подпрограмма updateCustomer выглядит довольно прилично. Похоже, что она реализует нужную нам логику – считывает запись, обновляет баланс и осуществляет запись обратно в файл. Однако, за внешним приличием и скрывается главная проблема. Подпрограммы readCustomer и writeCustomer тесно связаны между собой [27] – они совместно используют глобальную переменную cFile. Подпрограмма readCustomer открывает файл и сохраняет указатель файла в переменной cFile, а подпрограмма writeCustomer использует сохраненный указатель для закрытия файла по окончании работы. Эта глобальная переменная даже не появляется в подпрограмме updateCustomer.
Почему эту программу можно считать неудачной? Представим несчастную даму-программистку из службы сопровождения, которой сказали, что спецификация изменилась – баланс должен обновляться только в том случае, если его новое значение неотрицательное. Дама открывает файл с исходным текстом и изменяет подпрограмму updateCustomer:
void updateCustomer(const char *fName, double newBalance) {
Customer cRec;
readCustomer(fName, &cRec);
if (newBalance >= 0.0) {
cRec.balance = newBalance;
writeCustomer(&cRec);
}
}
Во время испытания все выглядит замечательно. Однако когда программа вводится в эксплуатацию, она «падает» через несколько часов, выдавая сообщение «Слишком много открытых файлов». Поскольку подпрограмма writeBalance в ряде случаев не вызывается, то и файл не закрывается.
У этой проблемы есть весьма неудачное решение – использовать специальный оператор выбора в подпрограмме updateCustomer:
void updateCustomer(const char *fName, double newBalance) {
Customer cRec;
readCustomer(fName, &cRec);
if (newBalance»= 0.0) {
cRec.balance = newBalance;
writeCustomer(&cRec);
}
else
fclose(cFile);
}
Это устраняет проблему – файл закроется независимо от нового значения баланса, но эта процедура означает, что теперь связанными оказываются три подпрограммы (через глобальную переменную cFile). Мы попадаем в ловушку, и если мы продолжаем действовать в том же духе, то все полетит под откос.
Подсказка «Доводите до конца то, что начинаете» говорит нам о том, что в идеале подпрограмма, которая назначает ресурс, обязана его и освобождать. Мы можем применить ее в данном случае, осуществляя небольшую реорганизацию программы:
void readCustomer(FILE *cFile, Customer *cRec) {
fread(cRec, sizeof(*cRec), 1, cFile);
}
void writeCustomer(FILE *cFile, Customer *cRec) {
rewind(cFile);
fwrite(cRec, sizeof(*cRec), 1, cFile);
}
void updateCustomer(const char *fName, double newBalance) {
FILE *cFile;
Customer cRec;
cFile = fopen(fName, «r+»); // ->>>
readCustomer(cFile, &cRec); //
if (newBalance >= 0.0) { //
cRec.balance = newBalance; //
writeCustomer(cFile, &cRec); //
} //
Fclose(cFile); // <<<-
}
Теперь всю ответственность за файл несет подпрограмма updateCustomer. Она открывает файл и (заканчивая то, что уже начала) закрывает его перед выходом. Подпрограмма осуществляет балансировку использования файла: открытие и закрытие происходят на одном и том же месте, и очевидно, что каждой процедуре открытия будет соответствовать процедура закрытия. Реорганизация также позволяет избавиться от уродливой глобальной переменной.
Базовая схема распределения ресурсов может быть распространена на подпрограммы, которым одновременно необходимо более одного ресурса. Поэтому есть еще два предложения:
1. Освобождайте ресурсы в последовательности, обратной той, в которой происходило их распределение. При этом можно избежать появления «осиротевших» ресурсов, если один из них содержит ссылки на другой.
2. При распределении одного и того же набора ресурсов в различных местах программы необходимо осуществлять эту операцию в одном и том же порядке. Это уменьшает вероятность взаимоблокировки. (Если процесс А требует resource1 и собирается затребовать resource2, тогда как процесс В затребовал resource2 и пытается заполучить resource1, то два процесса окажутся в состоянии вечного ожидания.)
Неважно, какой тип ресурсов используется, – транзакции, память, файлы, потоки, окна, к ним применима общая схема: кто бы ни назначал ресурс, он обязан нести ответственность за его освобождение. Однако эта концепция может получить дальнейшее развитие при работе с рядом языков программирования.
Объекты и исключения
Равновесие между распределениями ресурсов и их освобождениями напоминает о равновесии конструктора и деструктора класса. Класс представляет ресурс, конструктор создает конкретный для этого типа ресурса объект, а деструктор удаляет его из вашей области действия.
Если вы программируете на объектно-ориентированном языке, то упаковка ресурсов в классы может принести пользу. Всякий раз, когда вам необходим конкретный тип ресурса, вы создаете экземпляр объекта указанного класса. Если объект выходит из области действия или повторно запрашивается сборщиком мусора, то деструктор объекта освобождает инкапсулированный ресурс.
Этот подход обладает определенными преимуществами при работе с языками программирования типа С++, где исключения могут входить в противоречие с освобождением ресурсов.
Балансировка и исключения
Языки, поддерживающие исключения, могут сделать процедуру освобождения ресурса нетривиальной. Как удостовериться, что все ресурсы, назначенные до возбуждения исключения, освобождены надлежащим образом? В некоторой степени ответ зависит от языка программирования.
Язык С++ поддерживает механизм исключений типа try…catch. К сожалению, это означает, что всегда существует по крайней мере два возможных варианта выхода из подпрограммы, которая перехватывает, а затем повторно возбуждает исключение:
void doSomething(void) {
Node *n = new Node;
try {
// do something
}
catch (…) {
delete n;
thow;
}
delete n;
}
Заметим, что созданный нами узел освобождается дважды – один раз во время нормального выхода из подпрограммы, а второй раз в обработчике исключений. Это явное нарушение принципа DRY и проблема в сопровождении, которая может возникнуть в любой момент.
Однако в наших интересах воспользоваться семантикой языка С++. Локальные объекты автоматически разрушаются при выходе из блока, в котором они находятся. Это дает нам несколько вариантов. Если обстоятельства позволяют, можно поменять n: оно обозначает не указатель, а реальный объект Node в стеке:
void doSomething1(void) {
Node n;
try {
// делаем что-либо
}
catch (…) {
throw;
}
}
В этом случае мы используем С++ для автоматического разрушения объекта Node независимо от того, возбуждено исключение или нет.
В случае, если замена указателя на объект невозможна, тот же самый эффект достигается при инкапсулировании ресурса (речь идет об указателе Node) в пределах другого класса.
// Класс оболочки для ресурсов Node
class NodeResource {
Node *n;
public:
NodeResource() {n = new Node;}
~NodeResource() {delete n;}
Node *operator ->() {return n;}
};
void doSomething2(void) {
NodeResource n;
try {
// do something
}
catch (…) {
throw;
}
}
Теперь класс-оболочка NodeResource выступает гарантом того, что при разрушении его объектов происходит и разрушение соответствующих узлов. Для удобства класс оболочка предоставляет оператор разыменования – », с тем чтобы пользователи могли обращаться к полям в инкапсулированном объекте Node напрямую.
Поскольку эта методика столь полезна, в стандартной библиотеке С++ имеется шаблонный класс autOjDtr, обеспечивающий автоматические оболочки для динамически размещаемых объектов.
void doSomething3(void) {
auto_ptr
// Обращение к узлу Node как р-»…
// В конце узел автоматически удаляется
}
В отличие от C++ язык Java реализует «ленивую» форму автоматического разрушения объекта. Объекты, ссылки на которые отсутствуют, считаются кандидатами на попадание в «мусор», и их метод finalize будет вызываться в любой момент, когда процедура сборки мусора будет претендовать на эти объекты. Представляя собой удобство для разработчиков, которым больше не приходится жаловаться на утечки памяти, в то же время он усложняет реализацию процедуры очистки ресурсов по схеме С + +. К счастью, разработчики языка Java глубокомысленно ввели компенсирующую языковую функцию – предложение finally. Если блок try содержит предложение finally, то часть программы, относящаяся к этому предложению, гарантированно исполняется только в том случае, если исполняется любая инструкция в блоке try. Неважно, возбуждается при этом исключение или нет (даже при выполнении оператора return программой в блоке try) – программа, относящаяся к предложению finally, будет выполнена. Это означает, что использование ресурса может быть сбалансировано с помощью программы типа:
public void doSomething() throws IOException {
File tmpFile = new File(tmpFileName);
FileWriter tmp = new FileWriter(tmpFile);
try {
// do some work
}
finally {
tmpFile.delete();
}
}
Подпрограмма использует промежуточный файл, который мы хотим удалить, независимо от того, как подпрограмма заканчивает свою работу. Блок finally позволяет нам выразить это в сжатой форме.
Случаи, при которых балансировка ресурсов невозможна
Возникают моменты, когда основная схема распределения ресурсов просто не годится. Обычно это происходит в программах, которые используют динамические структуры данных. Одна подпрограмма выделяет область в памяти и связывает ее в структуру большего размера, где она и находится в течение некоторого времени.
Хитрость здесь состоит в установлении семантического инварианта для выделения памяти. Необходимо решить, кто несет ответственность за данные в составной структуре. Что произойдет при освобождении структуры верхнего уровня? Есть три основных варианта развития событий:
1. Структура верхнего уровня также несет ответственность за освобождение любых входящих в нее подструктур. Затем эти структуры рекурсивно удалят данные, содержащиеся в них, и т. д.
2. Структура верхнего уровня просто освобождается. Любые структуры, на которые она указывает (и на которых нет других ссылок), становятся «осиротевшими».
3. Структура верхнего уровня отказывается освобождать себя, если в нее входят какие-либо подструктуры.
В этом случае выбор зависит от условий, в которых находится каждая взятая в отдельности структура данных. Однако этот выбор должен быть явным для каждого случая, и ваше решение должно реализовываться последовательно. Реализация любого из представленных вариантов на процедурном языке программирования типа С может представлять проблему: структуры данных сами по себе не являются активными. В этих условиях для каждой из основных структур предпочтительнее написать модуль, обеспечивающий стандартные средства распределения и освобождения. (Этот модуль также обеспечивает распечатку результатов отладки, преобразование в последовательную и параллельную формы и средства обхода.)
И наконец, если отслеживание ресурсов становится слишком хитрой процедурой, можно создать собственную форму ограниченной автоматической сборки «мусора», реализуя схему подсчета ссылок для ваших динамически распределенных объектов. В книге «More Effective С++» ([Меу9б]) этой теме посвящен целый раздел.
Проверка баланса
Поскольку прагматики не доверяют никому, включая авторов книги, то мы полагаем, что во всех случаях неплохо было бы написать такую программу, которая осуществляла бы реальную проверку того, освобождены ли ресурсы надлежащим образом. Для большинства приложений это обычно означает создание оболочек для каждого типа ресурса и их использование для отслеживания всех распределений и освобождений. В некоторых точках программы логика диктует, что ресурсы находятся в определенном состоянии; для проверки этого и необходимо использовать оболочки.
Например, в программе, выполняемой на протяжении длительного времени и обслуживающей запросы, наверняка есть одна-единственная точка в начале основного цикла обработки, в которой происходит ожидание прихода следующего запроса. Именно в этой точке можно получить подтверждение тому, что с момента последнего выполнения цикла использование ресурсов не увеличилось.
При работе на более низком (но не менее полезном) уровне можно потратиться на инструментальные средства, которые (помимо всего прочего) проверяют выполняемые программы на наличие утечек памяти (регулярного неосвобождения области памяти). Весьма популярными являются Purify (www.rational.com) и Insure++ (www.parasoft.com).
• Проектирование по контракту
• Программирование утверждений
• Несвязанность и закон Деметера
• Несмотря на то, что не существует надежных способов удостовериться в том, что вы освободили ресурсы, в этом могут помочь некоторые технологии проектирования, если их применять последовательно. В данной главе обсуждалось, как установить семантический инвариант, с тем чтобы основные структуры данных могли управлять освобождением памяти. Подумайте, как с помощью принципа «Проектирование по контракту» можно было бы усовершенствовать эту идею.
22. Некоторые разработчики программ на С и С++ обращают особое внимание на необходимость установки указателя в NULL после освобождения области памяти, на которую он ссылается. Почему это можно считать удачной идеей? (Ответ см. в Приложении В.)
23. Некоторые разработчики программ на языке Java обращают особое внимание на необходимость установки объектной переменной в NULL после окончания использования объекта. Почему это можно считать удачной идеей? (Ответ см. в Приложении В.)