...
DWORD OpenFileContents(char *szFileName) {
assert(szFileName != NULL);
assert(strlen(szFileName) > 3);
FILE *f = fopen(szFileName, "r");
assert(f);
// Можно работать с файлом
return 1;
}
Греховность C/C++ в Windows
Мы уже говорили, что в Windows есть функции олицетворения, которые могут завершаться неудачно. Более того, в Windows Server 2003 появилась новая привилегия, которая разрешает выполнять олицетворение только определенным учетным записям, например службам (LocalSystem, LocalService и NetworkService), а также администраторам. Следовательно, ваша программа может не сработать при таком вызове функции олицетворения:
...
ImpersonateNamedPipeClient(hPipe);
DeleteFile(szFileName);
RevertToSelf();
Проблема в том, что если процесс работает от имени LocalSystem, а вызывает этот код низкопривилегированный пользователь, то обращение к DeleteFile может завершиться с ошибкой, так как у пользователя нет доступа к файлу. Надо полагать, именно этого вы и хотели. Но если функция олицетворения возвращает ошибку, то поток продолжает работать в контексте той учетной записи, от имени которой был запущен процесс. А это LocalSystem, и у нее, скорее всего, есть право на удаление файла! Итак, низкопривилегированный пользователь только что удалил ценный файл!
В следующем примере обрабатываются все вообще исключения. Механизм структурной обработки исключений (SEH) в Windows работает для любого языка:
...
char *ReallySafeStrCopy(char *dest, const char *src) {
__try {
return strcpy(dst, src);
} __except (EXCEPTION_EXECUTE_HANDLER) {
// замаскировать ошибку
}
return dst;
}
Если в strcpy происходит ошибка из–за того, что длина src больше длины dest или src равно NULL, то вы понятия не имеете, в каком состоянии осталось приложение. Содержимое dst корректно? В зависимости от того, где размещен буфер dest, каково состояние кучи или стека? Ничего не известно, но приложение будет продолжать работать, возможно, даже несколько часов, пока, наконец, с грохотом не рухнет. Поскольку разрыв во времени между моментом ошибки и окончательным сбоем так велик, никакая отладка не поможет. Не поступайте так.
Греховность С++
В следующем примере оператор new не возбуждает исключения, поскольку вы явно запретили компилятору это делать! Если внутри new возникнет ошибка, а вы попробуете воспользоваться переменной р, беды не миновать.
...
try {
struct BigThing { double _d[16999]; };
BigThing *p = new (std::nothrow) BigThing[14999];
// воспользуемся p
} catch(std::bad_alloc& err) {
// обработать ошибку
}
В примере ниже программа ожидает исключения std::bad_alloc, но работает с библиотекой Microsoft Foundation Classes, в которой оператор new возбуждает исключение CMemory Exception:
...
try {
CString str = new CString(szSomeReallyLongString);
// воспользуемся str
} catch(std::bad_alloc& err) {
// обработать ошибку
}
Греховность C#, VB.NET и Java
На примере показанного ниже псевдокода демонстрируется, как не следует обрабатывать исключения. Здесь перехватываются все возможные исключения, а это, как и приведенный выше пример Windows SEH, может замаскировать ошибки.
...
try {
// (1) Загрузить XML-файл с диска
// (2) Извлечь из XML-данных URI
// (3) Открыть хранилище клиентских сертификатов и достать оттуда
// сертификат в формате X.509 и закрытый ключ клиента
// (4) Выполнить запрос на аутентификацию к серверу, определенному
// на шаге (2), используя сертификат и ключ из шага (3)
} catch (Exception e) {
// Обработать все возможные ошибки,
// включая и те, о которых я ничего не знаю
}
Упомянутые в этом примере функции могут возбуждать самые разнообразные исключения. Если речь идет о каркасе .NET, то к ним относятся: SecurityEx–ception, XmlException, IOException, ArgumentException, ObjectDisposedExcep–tion, NotSupportedException, FileNotFoimdException и SocketException. Ваша часть программы действительно знает, как все их корректно обработать?
Не поймите меня неправильно. Иногда перехват всех исключений – вещь совершенно нормальная, только убедитесь, что вы понимаете то, что делаете.
Родственные грехи
Этот грех стоит особняком, никакие другие с ним не связаны. Впрочем, первая его разновидность обсуждается более подробно в грехе 13.
Так просто и не скажешь, нет характерных признаков. Самый эффективный способ – провести анализ кода.
Выявление ошибки на этапе анализа кода
Читать дальше
Конец ознакомительного отрывка
Купить книгу