avva | об ошибках (Reply)

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

Это интересная мысль - спрашивать "почему" и настаивать на осмысленном объяснении ошибки. Мне она, в такой форме общего принципа, не приходила в голову, хотя на практике я неоднократно так поступал (в роли программиста).

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

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

Скажем, ты находишься в графическом редакторе, и сохраняешь файл. В зависимости от того, где ты его сохраняешь, это может быть жесткий диск твоего компьютера или сетевая папка на сервере. Графический редактор не должен об этом ничего знать - он всего лишь пытается записать записать файл, а уже другие модули в операционной системе решают, послать этот файл на местный диск или по сети на другой компьютер. Теперь предположим, что по какой-то причине сохранить файл не удалось и программа-редактор получила код ошибки. Не так уж легко спроектировать интерфейс между программой и операционной системой так, чтобы он содержал полезную информацию о такой ошибке во всех случаях, и вместе с тем сохранить информационный барьер между программой и драйверами диска/сети, не заставлять программу что-то о них знать. Может, файл не записался оттого, что неожиданно свалился роутер, находящийся между твоим компьютером и сервером. Твое приложение не знает, что такое "роутер" и сетевые неполадки и не умеет объяснить это тебе внутри своего интерфейса, с ограничениями своего дизайна, понятным тебе языком. Ему (и его программистам) вообще ничего не хочется знать о сети, а только о том, как картинки редактировать. Оно всего лишь хотело записать файл, и это не удалось. Вот оно и пишет "Operation failed" или еще что-то в этом роде.

В примере из записи по ссылке - "удаленный хост не отвечает" - есть какой-то в цепочке роутеров от моего компьютера до хоста, который послал пакет следующему в цепочке, но не получил ответ. Ясно, что есть частные случаи, которые особенно интересны мне - например, если пакет не получен уже первым роутером, можно предположить какие-то проблемы с моим сетевым кабелем или домашним (рабочим) роутером; если получен последним, но не хостом, можно предположить проблему с удаленным сервером. Сейчас же я даже не знаю, получив такую ошибку, это у меня упал интернет или "там" что-то нет так, и должен делать дополнительные проверки, чтобы это узнать. Мне, программисту с опытом системной администрации, это сделать легко, но я не обычный пользователь. Все это - результат того, что протокол IP принципиально однонаправлен и настроен на то, чтобы роутер, отправив IP-пакет к следующему узлу, мгновенно забывал о нем. Лего понять, почему так спроектировано, из прагматических соображений; но мы платим за это, в частностью, вышеописанной непрозрачностью сбоев.