об ошибках

[avva]

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

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

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

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

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

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

Comments

[(Anonymous)]

>настаивать на осмысленном объяснении ошибки

любопытно, насколько востребованы такие объяснения. варианты действий после объявления об ошибке, пожалуй, были бы конструктивней. try again later - мне кажется много полезней, чем указание на крайнего.

[3d-object.livejournal.com]

Совершенно не согласен. try again later я и сам могу сообразить, а вот узнать, отчего произошел сбой - полезно.

Кто "пользователь"?

[(Anonymous)]

Требуемая степень подробности сообщений об ошибках и соответственно организация их выдачи зависит от того, кто есть "пользователь", какие ошибки он в принципе способен обработать. Для каждого модуля "пользователем" является вызывающий его модуль. Я обычно делаю так, объявляю один перечислимый тип, включающий все возможные коды ошибок всех модулей, причём каждому модулю выделяю некий диапазон значений. Модуль верхнего уровня, непосредственно общающийся с пользователем-человеком (если он есть) выводит только свою ошибку, но если этого недостаточно, можно запросить ошибку нижележащего модуля, и т.д. до упора. Каждому коду соответствует текстовое сообщение.

[igorlord.livejournal.com]

I think you are describing the thinking that was more applicable a few decades ago than now, when resource bean-counting (be it RAM bytes or bytes sent over a network) was very important. Today, these considerations may remain only in embedded devices and wireless networks (and their paramount importance is diminishing even there).

For today, this sounds like a cope-out rather than an attempt to fix a problem.

I would like to split this problem into two parts:

1. Informational (provide accurate and detailed error reports).

2. Functional (provide information necessary for some higher layer to automatically correct the problem).

The solution to the Informational problem actually seems simple. We already have a Universal informational data structure: a text string. We should also respect module layering as the prevalent system organization, with each higher layer providing a more "user-friendly" abstraction. Hence, I'd propose a List of Text Strings. Each higher-level layer is able to append a more user-friendly error description, while retaining the root cause error.

Since the data structure of "a list of strings" is brain-dead simple, all modules can expect to adhere to this simple convention.

That way, your editor's Top error may be something like:
"Save operation failed". Then, GUI would give an option: "more information", which would unfold the next error: "Network error". "More information" here would unfold: "Foreign host xyz.com unreachable". Depending on the network stack implementation (and no one higher up should care), it may have even more information: "some trace route information".


2. The "Functional" problem seems a bit harder, since it needs information that can be parsed by a computer, which necessities a predefined shared structure/API specification. It seems that here, the best thing we can do is introspective, backward-compatible APIs. That's a lot more fragile and cumbersome. :(

[saccovanzetti.livejournal.com]

there is often not enough information even to manually fix the problem, without diving into assembler codes.

[angerona.livejournal.com]

I'd propose a List of Text Strings. Each higher-level layer is able to append a more user-friendly error description, while retaining the root cause error.

Talk to me more about that. I think I know someone who once wrote a patent application for something very much like that. (ahem :) )

[psilogic.livejournal.com]

У меня в Bard-е все на модулях сделано, но с ошибками, тем не менее, проблем нет.

Схеима такая:

1. Объект x класса X, который что-то делает, и может "делать" с ошибками.
2. Абстрактный базовый класс ErrorHandler, у которого виртуальная функция 'erro' (на входе - текст ошибки и код).
3. Отнаследованные от ErrorHandler классы, показывающие ошибки так или эдак (в консоли, в окне, в логе и т.п.)

Допустим, некий модуль использует объекты разных классов, которые могут генерировать ошибки. Перед использованием модуль создает (или берет откуда-нибудь) объект ErrorHandler - такой, какой ему нужен, в зависимости от того, как хочет показывать ошибки. ErrorHandler назначается всем объектам, генерящим ошибки. Объект x в случае ошибки формирует текст ошибки и вызывает 'erro'. Он знает все о причинах ошибки (поскольку сам выполнил "ошибкоопасные" действия) но не знает ничего о том, как она будет показана юзеру.

И фсе работает :)

[alexeybobkov]

А почему метод называется 'erro'? Что (или кто), собственно, имеется в виду?

[msh.livejournal.com]

Это очень интересный вопрос. Я считаю, что выдать наиболее точное и подробное "почему" - это не цель. Цель - выдать ту информацию, которой я могу воспользоваться.

Пара примеров:

1. Компилятор когда не может что-то скомпилировать должен давать максимум информации почему. Оптимально - ссылку на нарушенное правило из стандарта языка. Я смогу прочитать и воспользоваться.
2. У меня дома стоит газовая отопительная печка. Если она не запускается, то я могу прочитать код ошибки (она передает его миганием лампочки). Кодов этих уйма, но доступных мне реакций на них только три - попробовать выключить и включить, проверить подачу газа, вызвать ремонтника. Подробный код мне совершенно не нужен и трех лампочек бы хватило вполне.

Из этих соображений на устройстве, которое мы делаем, есть лампочка "соединение с интернетом работает" - лампочка горит, а сайт не открывается - проблема с тем сайтом, лампочка не горит - звоните в свой "интернет" ;-)

[meshko.livejournal.com]

Она мигает не только для Вас, но и для этого ремонтника.
Моя плита вот вообше показала номер телефона, по которому надо было звонить, чтобы пришел ремонтник. Ну и кодовый номер ошибки показала. Пришел ремонтник, впечатал код ошибки в гугл, нашел номер детали, который надо было заменить, сказал, что мне будет выгодней самому купить и поставить, взял 50 зеленых и ушел. Вот я теперь думаю: хорошо что она мне номер телефона дала или нет? Если бы помалкивала, у меня было бы на 50 больше...

[http://users.livejournal.com/_rowan_tree_/]

NullPointerException :-)
А всего-то надо спускать сверху информацию, добавляя на каждом уровне, чтобы потом, если надо, собрать ее в сообщение об ошибке.

[pargentum.livejournal.com]

Мне кажется, описанная проблема могла бы быть относительно легко решена, если бы вместе с кодом ошибки подсистема выдавала бы текстовое сообщение, соответствующее этой ошибке. А вышележащая подсистема добавляла бы к этому сообщению текст о том, что она пыталась сделать, когда пришла эта ошибка.

То есть отвал сетевого диска выглядел бы как:
"ошибка при сохранении файла h:\mypicture.bml: no route to host". И пользователю было бы достаточно вспомнить, что у него диск h: сетевой.

[zanuda.livejournal.com]

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

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

[qaraabayna.livejournal.com]

В C++ задача решается каскадом try catch throw оборотов. Try элементарную операцию, catch ошибку, тут же сообщил на низком уровне, throw дальше. Все это обернуто в другой try, который выдает более общее сообщение об ошибке в контексте вызова элементарной операции и так далее.

Пример: сообщения make. Никто же не ругается на сообщения об ошибках makе...

У сообщения об ошибках есть две крайности: сказать сам дурак, или абсолютно точно заметить, что накрылся блок 3 в функции 5 модуля 7. Как не езди между двумя крайностями, либо юзеру будет непонятны технические детали, либо неопределенность сообщения опять таки сделает сообщение об ошибке невразумительным. Можно запросто скомбинировать и то и другое.

Обычно люди стараются моделировать ситуации об ошибках и дают двухходовое пояснение: (1) сервер накрылся (2) скорее всего, из-за того, что юзер засандалил черезчур много последовательностей.

[qaraabayna.livejournal.com]

Собственно об этом и писал _rowen_tree_

http://avva.livejournal.com/2046108.html?thread=59199388#t59199388

логи, логи, логи

[meshko.livejournal.com]

У меня очень мало опыта написания софта, с которым имеет дело конечный пользователь, но мой опыт написания серверного софта и системного администрирования говорит, что самое главное (и вполне осуществимое) -- это чтобы в случае возникновения внештатной ситуации профессионалу было легко понять, что случилось. А значит нужно писать логи. Много подробных логов с подробным отчетом об ошибке на всех уровнях, которые она затронула. И ещё эти логи должны быть сделаны так, чтобы их можно было найти.
На самом деле это сработает и в примере с сохранением файла на сетевой диск. На самом деле что ты тут пользователю не говори, а девочка-дизайнер не должна вообще быть в курсе, что её домашняя директория находится не на её компьютере, а на сервере. Но вот когда она звонит своему сисадмину и просит помочь, он должен сразу видеть в каком-нибудь application event log, что
failed to write h:\work\logo.png;
failure while accessing network drive h: mapped from \\fs4\homedirs\lisa
WINS resolution for fs4 failed;
failed to resolve hostname: 'fs4';
timed out while waiting for DNS query response from 192.168.1.2

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

[alon_68]

У меня очень мало опыта написания софта, с которым имеет дело конечный пользователь...

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

[white-lee.livejournal.com]

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

Я упомяну об еще одной важной причине - она хорошо прослеживается в посте и в комментариях, и интересно видеть, насколько она воспринимается, как нечто само собой разумеющееся. Сообщения об ошибках пишутся программистами, а должны бы писаться юзабилистами, или кому как угодно их называть. Это не пренебрежение по отношению к программистам, просто написание качественных сообщений об ошибках это действительно нетривиальная задача, и есть профессия, частью которой это является. Одна из причин, почему программистам лучше этим не заниматься - когда ты "слишком" хорошо знаешь систему, бывает крайне трудно абстрагироваться от этого, и представить себя в роли пользователя. Трудно понять, что является необходимой информацией, и трудно дать действительно полезные указания к действию (а они действительно необходимы, как упомянули выше). Указание "Обратитесь к сисадмину" будет обычно более верным, чем указание идти копаться в .ini файле. Верным "политически", потому что в данной фирме копаться в ini файлах - задача сисадминов, а не юзеров, и верным практически, потому что юзер может просто войти в ступор. А человеку, для которого решение копаться в файле намного более самоочевидно, чем решение звать сисадмина, который в этом понимает значительно меньше его самого, бывает сложно это понять.

И есть еще одна распространенная проблема - людям часто лень писать множество подробных сообщений, когда можно обойтись одним общим. Типа "Проверьте, нет ли в названии файла запрещенных символов: ! @ # $ % ^ & * ( ) < >" вместо того, чтоб сказать конкретно, какой запрещенный символ найден.

[alon_68]

+1
Они часть дизайна и должны писаться теми же, кто пишет меню, расставляет элементы GUI... А то ведь иногда в пользовательской программе видишь что-то типа "Virtual function unresolved". И куда с этим бедному бухгалтеру или статистику? :)

[anonymous8216.livejournal.com]

если бы все хотя бы пользовались strerror (3), так ведь и этого не дождешься...

[gruimed.livejournal.com]

Ни один маркетолог не пропостит в продукте сообщение об ошибке с пояснением "почему". И будет прав, ибо среднему пользователю это пояснение ничем не поможет, скорее еще больше напугает.

Рассчитывать на то, что сообщение об ошибке будет не только подробным, но еще и будет каким-то образом автоматически анализоривано и даст пользователю конкретные рекомендации, например "перезапусти ADSL router" наивно, это слишком сложно.

Вне зависимости от подробности информации в сообщении об ошибке средий пользователь сделает одно из двух - или попробует еще раз (как вариант после ребута) или обратится за помощью.

Продвинутым пользователям это было бы полезно, но их меньшенство.

[anonymous8216.livejournal.com]

если пояснение скрыть за кнопкой «подробности», никакой маркетолог не придерется.

[s1m.livejournal.com]

"Networking error" гораздо инофрмативнее, чем "no ACK received from router XXX:XX". Какая разница почему не удалось доставить? Главное, что не удалось. Более детально имеет смысл рапортовать только ошибки, которые пользователь может починить: "No paper in the printer", "File is read only", etc.

Что делать полезно, так это давать пользователю возможность что-то сделать. Добавление кнопки "Report Error" к диалогу об ошибке ведет к магическому сокращению звонков в службу поддержки ;)

[avva.livejournal.com]

Я не предлагаю говорить пользователю "no ACK received from router XXX:XX", я предлагаю сказать ему как минимум "you lost your connection to the Internet", если это можно определить, или "the site xyz.com is not functioning at the moment", если это можно определить (а вместе - это 90% таких ошибок).

[vaggie.livejournal.com]

то есть в идеале не 404, а "дорогой юзер, сегодня первое марта, а ты как обычно забыл оплатить интернет на месяц вперёд. сказать, где валяется твоя кредитная карточка? да-нет-отменить?"

[avva.livejournal.com]

Да, а что, разве это выглядит странным? Если вам банкомат скажет не "у вас на счету не осталось денег", а "ошибка 314897", какие слова вы в сердцах захотите сказать тому, кто спроектировал этот банкомат?

[b0rg.livejournal.com]

Вот интересно зачем детальные сообщения о неконтролируемых ошибках, если 90% пользователей хватит: we love you, try again.

Для продвинутых юзеров, возможно и понадобится детальное "module xxx can't reach the host yyy using protocol zzz" и стак трейс на сто строк, но что-то я сомневаюсь.

[avva.livejournal.com]

Поясняю еще раз на примере. Я пытаюсь зайти на сайт, мне выдает ошибку "cannot reach host". В 99% случаев эта ошибка вызвана одной из двух причин: либо у меня нет интернета вообще, либо вина того сайта, и я ничего не могу сделать. Причем try again почти всегда не помогает. Для меня, пользователя, важно знать, какая из двух причин верна, потому что первую я могу исправить, и кроме того, она мешает мне гораздо больше, чем вторая. Информацию о том, какая из двух причин верна, можно было бы мне представить, но сеть спроектирована так, что она теряется к тому моменту, когда браузер должен мне что-то написать. Это не есть хорошо. "we love you, try again" тут не поможет. Единственное, что поможет - совет "попробуйте открыть другой сайт, например гугль, и посмотреть, открывается ли он - если нет, скорее всего проблема у вас". Это нетривиальная инструкция для кого-то, кто не разбирается в техническом устройстве интернета, потому что это ему не нужно. Притом а) это нигде не написано, юзеры должны до этого дойти сами или научиться друг у друга; б) браузер, хотя мог бы это сделать за меня в фоновом режиме и сообщить мне что-то полезное, не делает.

[vodianoj.livejournal.com]

В блоге у Тёмы я ответил так:
http://tema.livejournal.com/286569.html?thread=125312873#t125312873
У тебя я не могу позволить подобной нездоровой лексики :-)
Приведённой мной пример ни в коем разе не претендует на полноту, но помоему он позволяет почувствовать, где должна проходить гранца между тем что можно, и что нельзя показывать пользователю в сообщениях об ошибках.

Т.е. если ворд не может записать на твой локальный харддиск, то он должен (и может) сообщить очень подробно почему он это не смог сделать. При этом, если он записывает на сетевое устройство, то часто единственное, что он должен (и обычно может сообщить) - это то, что устройство недоступно. Разумеется он может (и опять таки должен)предложить бейсик траблшутинг, типа, проверьте ваше подсоединение к интернет, и т.п., но вполне естественно, что в 90% случаев прийдётся позвонить в IT.

[http://users.livejournal.com/_winnie/]

Это частично наследие C и его стандартной библиотеки, где вместо одного int протащить через 20 функций список строк - нереально.

Лично я стараюсь считать что ошибка - это строка, часто её можно протащить между процессами, довольно часто среда это позволяет. Например, svn -> мой python скрипт -> visual studio.

[taganay.livejournal.com]

Помимо всего перечисленного выше, иногда пользователь просто не сможет понять ответ на вопрос "почему". Например, для программиста очень удобно, чтобы веб приложение вываливало на экран stack trace - это и есть исчерпывающий ответ "почему". Однако пользователя такой ответ просто напугает. Более того, этот ответ ему и не нужен - его дело платить деньги и хавать, что дают для этого как раз и существует служба техподдержки.

[freeborn.livejournal.com]

Не могу сохранить файл. Почему? Операционная система (ссылка на вики) вернула код ошибки 12345 (ссылка на MSDN). Попробуйте переустановить (ссылка на форум) ОС или купить новый компьютер (ссылка на Dell).

На самом деле лампочки "Check engine" вполне достаточно, чтобы дать понять пользователю - пора ехать к механику %)

[smalgin.livejournal.com]

вот потому я люблю AOP и с уважением отношусь к идее, воплощенной в Spring.

Хотя, конечно, платишь за это появлением еще слоя потрохов :)

[sayakosushi.livejournal.com]

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

[http://users.livejournal.com/_winnie/]

Мда. Я хоть и программист, но даже для меня это выглядит пугающее.
http://dobrokot.ru/pics/nya2009-05-10__22-32-21_31kb.png