Ошибочные предположения

Это перевод Erroneous assumptions. Автор: Ларри Остерман.

Замечал ли кто-нибудь из вас, что во всей документации Win32 для каждой функции есть что-то такое:

Возвращаемые значения

Если функция выполняется успешно - возвращаемое значение будет NO_ERROR.

Если функция выполняется неудачно - возвращаемое значение будет одним из следующих кодов ошибок:

Значение	Смысл
ERROR_INVALID_PARAMETER	Что-то об ошибке ERROR_INVALID_PARAMETER
Прочие	Код системной ошибки, описанный в WinError.h.

Я не могу даже представить, сколько раз люди жаловались на эту последнюю строку в таблице. Почему, чёрт побери, в Microsoft не могут документировать ошибки, возвращаемые этой функцией? Они там совсем тупые или ленивые, что-ли?

Вообще-то ответ гораздо проще. Мы уже пробовали такое раньше и нас за это довольно сильно стукнуло по лбу. И мы не хотим попасть под удар снова.

На моём столе лежит памятный кусок прошлого под названием MS-DOS 2.0 reference manual (опубликован Microsoft в 1984). На странице 1-143, около описания API Create Handle (MS-DOS-овский эквивалент вызова open), указывается, что API может возвращать такие значения:

      Carry set:
    AX
          3 = Path not found
          4 = Too many open files
          5 = Access denied

Да, вот так. Документация Microsoft (и IBM) когда-то указывала полный список возвращаемых ошибок для всех функций DOS. Фактически мы сказали нашим клиентам, что ЕДИНСТВЕННЫМИ кодами ошибок, которые возвращаются API INT 21 0x3DH, являются коды 3, 4 и 5. И знаете что? Наши клиенты поверили нам. И они писали свои программы в соответствии с этим предположением.

Ну, а потом пришёл DOS 3.1, который добавил поддержку сети (networking). А с этим появились и новые причины для неудачного завершения этого вызова API. Например, “Network path not found” (открываемый файл располагается на сервере, но сервер не в сети). Или “Sharing Violation” (кто-то ещё открыл этот файл и заблокировал его).

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

И тогда мы поняли, насколько же ошибочным было это предположение. Программы вылетали налево и направо. Вылетало КАЖДОЕ приложение. Почему? Потому что Microsoft и IBM сказали им всем, что они никогда в жизни не увидят коды ошибок, отличные от 3, 4 или 5. А поскольку RAM была одним из самых ценных ресурсов тогда, разработчики программ не стали тратить ценное место на код, реализующий абсолютно бесполезную функциональность проверки на коды ошибок, который никогда и не возникнут. Когда ваша программа хочет работать на машине с 64 Kб RAM, то надёжное программирование отходит на второй план.

Тогда Microsoft придумало таблицу соответствия кодов ошибок DOS (DOS error mapping table). Она определила соответствие между всеми новыми и старыми кодами ошибок. Чтобы получить НАСТОЯЩИЙ код ошибки, вам нужно было вызвать функцию “Get Extended Error”, которая возвращала вам “настоящую” причину неудачного вызова.

Эта таблица существует до сих пор в исходниках Longhorn (я взглянул на днях из любопытства). Она располагается в исходниках NTVDM, поэтому она не является частью логики Win32, но суть в том, что она всё ещё здесь, с нами. И вероятнее всего мы никогда не избавимся от неё (ну, мы не можем убрать её, пока мы не уберём поддержку 16-ти битных приложений, что точно будет ещё не скоро).

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