Здравствуйте, 0K, Вы писали:

0K>Простите, слишком узко смотрите. Программа зачастую не знает что пользователь хранит в файле. Нужно выдать конкретное имя файла, с которым проблема. Как вы это сделаете?

Если честно, то конечный пользователь вообще зачастую не знает, что программа что-то там хранит в файлах, что-то в реестре, а что-то — в базе данных или вообще тянет из веба. Сообщения программы, которые получает пользователь, должны быть четко завязаны на:

а) кейзы, описанные в справочнике-помощи, поставляемой с программой, которые позволяют понять смысл сообщения и дают варианты решения проблемы. Читай: "При нажатии кнопки "вкл" лампочка "Вкл" не загорается — проверьте подключена ли вилка к розетке".

б) ситуации, которые пользователь не может решить самостоятельно, но которые могут объяснить службе поддержки что вообще происходит. Далее — см. по этапам процесса поддержки ПО.

На этом, собственно, все. То, что пользователь может быть умнее, чем рядовой потребитель — ни о чем не говорит. Если пользователь умнее и инструмент-программа на это рассчитан — рассчитан на то, что им будет пользоваться именно умный пользователь — ситуация при этом ровным счетом не меняется, только сообщения уровня а) становятся шире и глубже — охватывают большее количество кейзов и позволяют делать более глубокую аналитику "что вообще происходит". Опять-таки, если программа пользуется файлом xxx213456.tmp как "внутренними данными" и в документации для _пользователя_ это не описано и вообще не предполагается, что пользователь будет об этом знать — сообщение "не могу открыть вайл кптфхцч2110345.var" не должны появляться в принципе. Разве что в качестве дополнительной расширенной информации к сообщениями типа б).

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

имхо, библиотеки уровня прикладного API сообщения о своих ошибках:

а) _должны_ предоставлять на уровне кодов прикладного API;
б) _могут_, но не должны, предоставлять сервис для формирования человеко-удобных сообшений на основании кода ошибки прикладного API.

Передавать наружу библиотекой уровня прикладного API сразу user-friendly сообщение — лично я считаю расточительством ресурсов, разве что данная библиотека — просто выделенная часть программного комплекса и отдельно все равно не поставляется и все управление ошибками в ней реализовано не на уровне библиотеки, но на уровне всего программного комплекса.

имхо, где-то так.

Здравствуйте, 0K, Вы писали:

0K>Вот! Теперь, похоже, вы поняли проблему. Вы же сами написали "Не факт, что e.Message содержит текст сообщения в читабельном виде... Мало ли, мож еще и перевести надо". Нужно перевести или нет -- зависит от локализации библиотеки. Если нет локализации -- добавить ее (это обязательно!).

имхо, лучше использовать отдельный сервис — отдельный API, включенный в библиотеку именно для этой цели — для выдачи по внутренним кодам сообщений об ошибках их user-friendly вариантов. Таким образом функционально несвязанные части разделяются, что облегчает и разработку, и тестирование, и сопровождение.

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

0K>А вот как узнать можно ли данное сообщение выводить пользователю? Является ли оно UserFriendly? Вот этого механизма и не хватает. Понимаете о чем речь? Ведь в сообщении могут быть очень полезные данные (имя файла, имя сетевой ошибки и пр.) а могут быть абсолютно не понятные пользователю контрактные данные (которые выводить ни в коем случае нельзя).

Вот именно в том и проблема: как библиотека может знать, что в полном отчете об ошибке, который она предоставляет в своем внутреннем формате — что из этого можно показывать пользователю, а что — нельзя? Это уровень приложения, использующего данную библиотеку — именно приложение получит полный отчет о возникшей ошибке и сформирует отчет уже для пользователя в соотв. со своими, приложения, политиками сообщений для пользователя.

M>>Если уж библиотека должна выдавать читабельные эксепшены

0K>А кто должен выдавать? Вот вызываете вы метод для перевода денег со счета на банковскую карту. И он выдает исключение: превышен лимит операций. А вы что пользователю скажите? НЕ удалось перевести средства? И все? А причину он откуда может узнать? Может просто сетевая ошибка? А может его счет заблокирован по подозрению в мошенничестве? А может денег нет? Откуда бедному пользователю узнать, что именно превышен лимит операций?

В простейшем случае: "НЕ удалось перевести средства?" (к) И все. А причину он может узнать, связавшись со службой поддержки по указанным координатам. Потому как на самом деле счет заблокирован, а карта — в розыске. А тому, кто запросил перевод денег, знать об этом не положено.

А не положено бедному пользователю знать!
Вот у нас снаружи библиотеки стоит простой фильтр: вот этот пользователь может увидеть только вот эти сообщения. Остальные показывать как "общая ошибка — обратитесь к администратору". И все. Решает что и как показывать — _приложение_, не библиотека.

Библиотека может в этом помочь, но обычно это все же overfunctionality, я так думаю. Т.е. в лучшем случае полезно, но не необходимо. В основном случае это еще и бесполезно и даже вредно. Разве что заказчик библиотеки прямо запросил подобную функциональность.

0K>Вот только как узнать является ли исключение контрактным или предназначено для вывода пользователю -- этого механизма нет.

Вот именно. Потому все сообщения должны быть контрактными. Если хочется сделать для вывода пользователю — отдельный сервис/API. Кстати, в Видне именно так.

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

0K>Зачем изменять, не понял?

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

0K>Ну хорошо. Вот возникла ошибка при попытке перевести деньги со счета на банковскую карту. Вы что напишите? Не удалось перевести средства? Причин же может быть десятки! И это очень важно для пользователя.

Простите, причины важны для того, кто этой библиотекой пользуется — т.е. для программы. Все эти десятки причин (я уже повторяюсь, да?) могут быть и в реальной практике должны быть тщательно отфильтрованы и программа сама должна на многие отдельные причины реагировать специальным образом. И решать это — программе. Если я, как владелец этой программы, предоставляющий сервис этой программы пользователю, посчитаю важным показать конкретную причину неудачи операции, я покажу. Если нет — нет. И это правильный подход. А иначе мы сваливаемся "к красивому" принципу написания программ, когда системная ошибка со своим исключением пропускается пользователю — ему ведь это важно! — скажем, в ответ на выдергивание сетевого кабеля ethernet из терминала — и таким образом позволяет пользователю как минимум, получить информацию, которая ему вообще-то и не предназначалась вовсе, а как максимум — получить и доступ к системе на уровне системы, а не приложения, которое пользователя должно обслуживать. Попробуйте как-нибудь проделать такую вещь с терминалами по продаже кодов пополнения сотовых операторов — они, терминалы, по всей стране расбросаны — опыт весьма занимательный!

Еще раз: библиотека пользователю _приложения_ ничего не должна — всем _обязано_ управлять именно приложение. И никак иначе. Впрочем, случаи когда таки иначе я тоже упомянул выше.

Здравствуйте, 0K, Вы писали:

0K>Еще раз повторяю: пользователю нужно отобразить только Message UserFriendlyException. Не любого Exceptin, а именно UserFriendly. Как его отличить -- в этом то и вопрос. Механизма нет, хотя должен быть.

Еще раз повторяю: механизма отличить ошибку user-friendly от не user-friendly на уровне _библиотеки_ быть не может в принципе и именно в принципе самой структуры "библиотека — приложение — user" быть не должно. Решать "user — не user" именно приложению, и никак иначе. Иначе сама библиотека уже перебирает на себя часть функций приложения и либо становится его, приложения, непосредственной частью (а не "библиотекой", как "собранием отдельных решений задач") и, собственно, становится самим приложением. Тогда уже библиотека пользуется функциями приложения для общения с пользователем.

0K>Простите, а каким образом вы предлагаете передавать сообщения об ошбках пользователю?

А зачем их передавать пользователю? Может я по плану хочу сперва 3 раза сделать Ку! — попробовать подключиться — и только потом выдать пользователю "А ннэ палучилась! Спробуйтэ щэ!"

0K>На конкретном примере. Библиотека для работы с финансовой системой. Метод для перевода средств со счета на карту. Клиент вызывает этот метод -- происходит ошибка. В Message -- детальное описание причины ошибки (причин может быть несколько десятков). Вы выведете это сообщение пользователю, или вы будете out-параметр добавлять в метод и описание ошибки в него записывать?

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

Здравствуйте, 0K, Вы писали:

0K>Здравсти! MSDN изредка почитывайте. Локализация сообщений об ошибках -- обязательное требование.



0K>Почему, по вашему, MS сами локализуют сообщения об ошибках в своей .Net платформе? Локализовать может и тот, кто будет использовать вашу библиотеку. Для этого перекомпиляция не нужна, есть специальная тулуза в SDK.

Мы говорим о .NET, как о framework, сиречь "библиотеке библиотек", включая в т.ч. и "специальный сервис для выдачи и локализации user-friendly сообщений", или как о библиотеке в более узком понимании?

А то Win API тоже как бы "библиотека", и там тоже есть генерация сообщений читаемых для пользователя и локализация этих сообщений. Что ж теперь — каждый отдельный контейнер специального образца тоже "пользоватевать и локализировать"?

0K>Локализация -- это не больно. Открываете файл ресурсов и быстренько переводите все UserFriendly-сообщения об ошибках.

имхо, вы говорите о чем-то очень-очень конкретном о своем, обобщая это очень-очень конкретное свое до совсем-совсем общего.