Исключения для пользователя и для программиста -- разница
От: 0K Ниоткуда  
Дата: 12.08.10 06:27
Оценка: 1 (1) -1
В продолжение темы об исключениях (см. тег).

90% Exception'ов генерируются для программиста. Для пользователя они не информативны. Они служат для реализации контрактов и инвариантов (к примеру, проверка аргументов функции на null).

Но некоторые Exception'ы содержат текст для пользователя: этот текст будет ему понятен и полезен. Как правило такие исключения генерируются ближе к выходу из конкретной библиотеки (т.е. на самом верхнем уровне) и они обрамляют все исключения контрактов (перехватывают контрактные исключения, т.к. нет смысла в ArgumentNullException выше самой библиотеки).

Почему их (эти 2 категории исключений) никак не отличают? Сделали бы стандарт: все исключения, содержащие информацию полезную для пользователя наследовать от UserFriendlyException. А остальные инсключения -- контрактные -- не должны показываться пользователю.

А то каков смысл выдвавать сообщение пользователю: ArgumentNullException parameter = value?

Вот вам практический пример глупости от Microsoft: http://rsdn.ru/Forum/Info/FAQ.rsdn.forum.xslt.aspx
Автор: nzeemin
Дата: 18.11.05
Exception Details: System.ArgumentException: Unsupported language. Это же исключение нарушения контракта. Его нужно было обрамить в CompilerException и написать пояснение: не удалось скомпилировать aspx-страницу, т.к. указан неподдерживаемый язык. А то поди догадайся.

14.08.10 00:03: Перенесено модератором из '.NET' — TK
exception
Re: Исключения для пользователя и для программиста -- разниц
От: Qbit86 Кипр
Дата: 12.08.10 06:36
Оценка: +1
Здравствуйте, 0K, Вы писали:

0K>90% Exception'ов генерируются для программиста. Для пользователя они не информативны.


Практически верно. Но ты смешиваешь в кучу исключения и сообщения исключений. Пользователю может отображаться не тот текст, который пришёл в исключении. В исключении приходит, скажем, «Нет ни одного элемента в таблице Accounts», пользователю транслируем: «Нет ни одного пользователя».

0K>Но некоторые Exception'ы содержат текст для пользователя: этот текст будет ему понятен и полезен.


И этот текст, в частности, должен быть локализован (переведён в ресурсах).

0K>Почему их (эти 2 категории исключений) никак не отличают?


Почему не отличают — некоторые отличают :)
Глаза у меня добрые, но рубашка — смирительная!
Re: Исключения для пользователя и для программиста -- разниц
От: SE Украина  
Дата: 12.08.10 06:37
Оценка:
Здравствуйте, 0K, Вы писали:

0K>В продолжение темы об исключениях (см. тег).


0K>90% Exception'ов генерируются для программиста. Для пользователя они не информативны. Они служат для реализации контрактов и инвариантов (к примеру, проверка аргументов функции на null).


0K>Почему их (эти 2 категории исключений) никак не отличают? Сделали бы стандарт: все исключения, содержащие информацию полезную для пользователя наследовать от UserFriendlyException. А остальные инсключения -- контрактные -- не должны показываться пользователю.


Насколько помню, для случаев нарушения целостности классов рекомендуется наследоваться от InvalidOperationException, для случаев нарушения работы программы (это именно случай, когда нужно сообщить об ошибке) от ApplicationException.
Что не так?
Re: Исключения для пользователя и для программиста -- разниц
От: mrjeka Россия  
Дата: 12.08.10 06:37
Оценка:
Здравствуйте, 0K, Вы писали:

0K>Но некоторые Exception'ы содержат текст для пользователя: этот текст будет ему понятен и полезен. Как правило такие исключения генерируются ближе к выходу из конкретной библиотеки (т.е. на самом верхнем уровне) и они обрамляют все исключения контрактов (перехватывают контрактные исключения, т.к. нет смысла в ArgumentNullException выше самой библиотеки).


И в этом случае пользователем является разработчик.

0K>Почему их (эти 2 категории исключений) никак не отличают? Сделали бы стандарт: все исключения, содержащие информацию полезную для пользователя наследовать от UserFriendlyException. А остальные инсключения -- контрактные -- не должны показываться пользователю.


0K>А то каков смысл выдвавать сообщение пользователю: ArgumentNullException parameter = value?


0K>Вот вам практический пример глупости от Microsoft: http://rsdn.ru/Forum/Info/FAQ.rsdn.forum.xslt.aspx
Автор: nzeemin
Дата: 18.11.05
Exception Details: System.ArgumentException: Unsupported language. Это же исключение нарушения контракта. Его нужно было обрамить в CompilerException и написать пояснение: не удалось скомпилировать aspx-страницу, т.к. указан неподдерживаемый язык. А то поди догадайся.


Как правило, все исключения поднимаются для разработчиков. Разработчик должен позаботится о том, чтобы пользователь увидел нормальное исключение, а не непонятную, для его мозга, информацию.
Вы можете вообще не выдавать пользователю никаких исключений, а писать свой текст на своё усмотрение, либо вообще придумать своё поведение приложения.
Re[2]: Исключения для пользователя и для программиста -- раз
От: Qbit86 Кипр
Дата: 12.08.10 06:39
Оценка: 8 (2)
Здравствуйте, SE, Вы писали:

SE>Насколько помню, для случаев нарушения целостности классов рекомендуется наследоваться от InvalidOperationException, для случаев нарушения работы программы (это именно случай, когда нужно сообщить об ошибке) от ApplicationException.

SE>Что не так?

От ApplicationException не рекомендуется наследоваться: «Do derive custom exceptions from the T:System.Exception class rather than the T:System.ApplicationException class.» http://msdn.microsoft.com/en-us/library/ms229007.aspx
Глаза у меня добрые, но рубашка — смирительная!
Re[2]: Исключения для пользователя и для программиста -- раз
От: 0K Ниоткуда  
Дата: 12.08.10 06:40
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Практически верно. Но ты смешиваешь в кучу исключения и сообщения исключений. Пользователю может отображаться не тот текст, который пришёл в исключении.


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

Q>В исключении приходит, скажем, «Нет ни одного элемента в таблице Accounts», пользователю транслируем: «Нет ни одного пользователя».


И как вы это будете делать? String.Replace?

Q>И этот текст, в частности, должен быть локализован (переведён в ресурсах).


Ага.

0K>>Почему их (эти 2 категории исключений) никак не отличают?


Q>Почему не отличают — некоторые отличают


Я имею в виду, что нужно наследовать от разных базовых классов. Должна быть структура и порядок.
Re[2]: Исключения для пользователя и для программиста -- раз
От: 0K Ниоткуда  
Дата: 12.08.10 06:43
Оценка:
Здравствуйте, SE, Вы писали:

SE>Насколько помню, для случаев нарушения целостности классов рекомендуется наследоваться от InvalidOperationException


Это инвариантное исключение. Для программиста.

SE>, для случаев нарушения работы программы (это именно случай, когда нужно сообщить об ошибке) от ApplicationException.


От ApplicationException ранее рекомендовали наследовать ВСЕ новые типы исключений (не системные). А теперь как?

SE>Что не так?


Должен быть базовый тип для UserFriendly исключений. Тест таких исключений 100% должен быть понятен пользователю. Иначе откуда я знаю выводить ли текст отловленного исключения пользователю или нет?
Re[3]: Исключения для пользователя и для программиста -- раз
От: SE Украина  
Дата: 12.08.10 06:45
Оценка: :)
Здравствуйте, Qbit86, Вы писали:

Q>Здравствуйте, SE, Вы писали:


SE>>Насколько помню, для случаев нарушения целостности классов рекомендуется наследоваться от InvalidOperationException, для случаев нарушения работы программы (это именно случай, когда нужно сообщить об ошибке) от ApplicationException.

SE>>Что не так?

Q>От ApplicationException не рекомендуется наследоваться: «Do derive custom exceptions from the T:System.Exception class rather than the T:System.ApplicationException class.» http://msdn.microsoft.com/en-us/library/ms229007.aspx


Ух, ты. Я отстал от жизни. Видно, читал рекомнедации еще когда, цитирую оотуда же:

It was originally thought that custom exceptions should derive from the ApplicationException class;


А оно вон как повернулось
Re[3]: Исключения для пользователя и для программиста -- раз
От: Qbit86 Кипр
Дата: 12.08.10 06:47
Оценка:
Здравствуйте, 0K, Вы писали:

Q>>В исключении приходит, скажем, «Нет ни одного элемента в таблице Accounts», пользователю транслируем: «Нет ни одного пользователя».


0K>И как вы это будете делать? String.Replace?


Нет. Библиотека не знает, с какими сущностями она работает, поэтому она выдаёт «обобщённые» сообщения, типа «Sequence contains no elements». Пользователю (разработчику-пользователю библиотеки) в момент вызова известен контекст, скажем, что работа происходит с залогинеными пользователями, а не просто с «элементами коллекции».

0K>Я имею в виду, что нужно наследовать от разных базовых классов. Должна быть структура и порядок.


В C++ иерархия стандартных исключений, AFAIR, была более упорядочена.
Глаза у меня добрые, но рубашка — смирительная!
Re[2]: Исключения для пользователя и для программиста -- раз
От: 0K Ниоткуда  
Дата: 12.08.10 06:47
Оценка:
Здравствуйте, mrjeka, Вы писали:

M>Как правило, все исключения поднимаются для разработчиков. Разработчик должен позаботится о том, чтобы пользователь увидел нормальное исключение, а не непонятную, для его мозга, информацию.


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

Если заранее не предусмотреть такие UserFriendly-исключения -- программист никак не сможет из ArgumentNull или еще чего сделать понятные пользователю.

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


Ага. И кто потом захочет использовать ваши программы? Не считайте пользователей за идиотов. Если возникла проблема с базой -- сообщите, они разбрутся. Если не доступен сервис -- выведите ошибку 403 или 500 -- 80% пользователей знают что это за ошибка или найдут в google.
Re[3]: Исключения для пользователя и для программиста -- раз
От: SE Украина  
Дата: 12.08.10 06:51
Оценка:
Здравствуйте, 0K, Вы писали:

SE>>Что не так?


0K>Должен быть базовый тип для UserFriendly исключений. Тест таких исключений 100% должен быть понятен пользователю. Иначе откуда я знаю выводить ли текст отловленного исключения пользователю или нет?


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

Необернутые исключения в таком случе, получается не были мной обработаны корректно и считаются мной такими, которые нарушили целостность, и программа должна быть закрыта с неким почти бесполезным комментарием "Все, капец, приплыли, произошло неведомое, извините".
Re[4]: Исключения для пользователя и для программиста -- раз
От: 0K Ниоткуда  
Дата: 12.08.10 06:55
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Нет. Библиотека не знает, с какими сущностями она работает, поэтому она выдаёт «обобщённые» сообщения, типа «Sequence contains no elements». Пользователю (разработчику-пользователю библиотеки) в момент вызова известен контекст, скажем, что работа происходит с залогинеными пользователями, а не просто с «элементами коллекции».


В том то и дело, что не всегда библиотека знает проблему хуже вызывающего кода (от вызывающего сокрыты детали). Вот при подключении к базе -- именно библиотека должна выдать UserFriendly-исключение. Вызывающий не знает в чем там проблема -- он просто может сказать удалось ли подключиться. Как он укажет Friendly-причины?

По поводу вашего примера. Давайте более подробно.
Re[4]: Исключения для пользователя и для программиста -- раз
От: 0K Ниоткуда  
Дата: 12.08.10 06:58
Оценка:
Здравствуйте, SE, Вы писали:

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


Правильный подход. Но это должно быть не на лично уровне, а на уровне соглашений.

А когда вы вызываете другие библиотеки откуда вы знаете какие исключения являются UserFriendly?

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


Вот не нужно спешить закрывать программу. Что вы для атомных электростанций или для больницы софт пишите?
Re[3]: Исключения для пользователя и для программиста -- раз
От: mrjeka Россия  
Дата: 12.08.10 07:11
Оценка:
Здравствуйте, 0K, Вы писали:

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


Уточните, кого вы подразумеваете под пользователем?
Для меня пользователь библиотеки это такой же разработчик, который смыслит в программировании.
Пользователь приложения — это человек, который к программированию не имеет ни какого отношения.

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


0K>Если заранее не предусмотреть такие UserFriendly-исключения -- программист никак не сможет из ArgumentNull или еще чего сделать понятные пользователю.


Если речь идет о том, какое сообщение выдавать конечному пользователю, то никто вам не мешает сделать что-то вроде


try
{
   //do something
}
catch(OutOfMemoryException e)
{
   Console.WriteLine("Friendly message");
   //throw new CustomException("Это уже на ваше воображение, как хотите так и фантазируйте");
   //throw; пинаем исключение наверх (я так делаю в библиотеках)
}




0K>Ага. И кто потом захочет использовать ваши программы? Не считайте пользователей за идиотов. Если возникла проблема с базой -- сообщите, они разбрутся.


Пользователей за идиотов никто не считает. Сообщить — не значит выдать Exception в том виде, в котором он есть.

0K>Если не доступен сервис -- выведите ошибку 403 или 500 -- 80% пользователей знают что это за ошибка или найдут в google.


значит ваш круг общения состоит из 80% программистов или по крайней мере продвинутых пользователей.
Re[5]: Исключения для пользователя и для программиста -- раз
От: Qbit86 Кипр
Дата: 12.08.10 07:30
Оценка: 4 (2) +1
Здравствуйте, 0K.

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

0K>В том то и дело, что не всегда библиотека знает проблему хуже вызывающего кода (от вызывающего сокрыты детали). Вот при подключении к базе -- именно библиотека должна выдать UserFriendly-исключение.


ApiUserFriendly-исключение, а не EndUserFriendly. Библиотека не знает, что для конечного пользователя будет более friendly: текст на корейском, формат даты ISO-8601, упоминание смещения в файле, начиная с которого пошли некорректные данные, etc. Библиотека даже не знает, будет ли конечным пользователем человек, или, скажем, сервис без пользовательского интерфейса.

Кроме того, помимо текста сообщения в кастомном ApiUserFriendly-исключении могут хранится и другие данные, уточняющие причину исключения.

0K>В том то и дело, что не всегда библиотека знает проблему хуже вызывающего кода (от вызывающего сокрыты детали).


Если библиотека скрывает детали, то это на совести автора библиотеки, он счёл это нужным, таков контракт библиотеки. В любом случае, если эти детали нужны и предоставляются, то они должны быть доступны через свойства исключения, а не через EndUserFriendly-сообщение. Не парсить же его, право слово, чтобы сформировать своё сообщение, скажем, на украинском языке?

0K>По поводу вашего примера. Давайте более подробно.


Рассмотрим стандартное исключение FileNotFoundException. Оно содержит ApiUserFriendly-сообщение «Could not find file 'temp_6B8FCD97.xml'.» плюс дополнительное поле ex.FileName, равное «temp_6B8FCD97.xml».
При трансляции конечному пользователю сообщение может превратиться в EndUserFriendly-сообщение, например, в такое: «Нет доступа к файлу с данными о днях рождения ваших друзей.»
Глаза у меня добрые, но рубашка — смирительная!
Re[4]: Исключения для пользователя и для программиста -- раз
От: 0K Ниоткуда  
Дата: 12.08.10 07:33
Оценка:
Здравствуйте, mrjeka, Вы писали:

M>Уточните, кого вы подразумеваете под пользователем?


Конечного пользователя. Тот, ради которого все и делаем.

M>Для меня пользователь библиотеки это такой же разработчик, который смыслит в программировании.

M>Пользователь приложения — это человек, который к программированию не имеет ни какого отношения.

Пользователь приложения использует и библиотеку. И в некоторых случаях именно библиотека должна выдвать UserFriendly-исключения.

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


Давайте на конкретных примерах. Библиотека для работы с базой. Не удалось подключиться. Есть детали ошибки, которые нужны и понятны пользователю. Как вы их передадите, чтобы пользователь внятно увидел все детали ошибки?

Или библиотека для работы с интерфейсами какого-нибудь финансового сервиса. 90% ошибок контрактные -- пользователю их ни в коем случае показывать нельзя. Но есть и UserFriendly -- исчерпан лимит операций, нет денег на счету и пр. Они понятны и нужны пользователю. Как программист, использующий вашу библиотеку узнает, что сообщение именно ЭТИХ исключений нужно отобразить пользователю?

M>
M>try
M>{
M>   //do something
M>}
M>catch(OutOfMemoryException e)
M>{
M>   Console.WriteLine("Friendly message");
M>   //throw new CustomException("Это уже на ваше воображение, как хотите так и фантазируйте");
M>   //throw; пинаем исключение наверх (я так делаю в библиотеках)
M>}
M>


Вы что не поняли? Речь не о системных исключениях. А о UserFriendly, которые содержат важный для пользователя Message.

M>Пользователей за идиотов никто не считает. Сообщить — не значит выдать Exception в том виде, в котором он есть.


Еще раз: контрактные исключения выдвать нельзя. UserFriendly нужно выдать, они содаржат важную информацию. Как вы отличаете исключения которые содержать важную для пользователю информацию от контрактных исключений?

M>значит ваш круг общения состоит из 80% программистов или по крайней мере продвинутых пользователей.


Вовсе нет. Вы недооцениваете людей. Намного понятее для 80% пользователей "не удалось подключиться к сервису ya.ru, проверьте подключение к интернету", чем "ошибка соединения".
Re[5]: Исключения для пользователя и для программиста -- раз
От: mrjeka Россия  
Дата: 12.08.10 08:00
Оценка: +3
Здравствуйте, 0K, Вы писали:

0K>Пользователь приложения использует и библиотеку. И в некоторых случаях именно библиотека должна выдвать UserFriendly-исключения.


Ну если уж у вас пользователи напрямую используют библиотеку, без какого либо UI-layer, тогда да. Этот вариант и нужен.

Я подразумевал стандартную архитектуру приложения.
UI работает с какой-либо библиотекой. Эта библиотека возвращает исключения в голом виде (как произошло так и возвращает).

Обработка в UI


try
{
Lib.GetData();
}
catch(Exception e)//Опустим пока подробности с типами исключений
{
  //Запись в лог
  Log.Write(e);
  //Вывод пользователю
  //Не факт, что e.Message содержит текст сообщения в читабельном виде... Мало ли, мож еще и перевести надо
  //Мало того, зачастую бывает что в e.Message вообще ничего разумного нет, а лежит в InnerException
  Console.WriteLine(GetFriendlyMessage(e));
}

private string GetFriendlyMessage(Exception e)
{
  //Делайте что хотите, как хотите, так и парсите этот эксепшн. Выдавайте какие угодно сообщения пользователю. 
}


0K>Или библиотека для работы с интерфейсами какого-нибудь финансового сервиса. 90% ошибок контрактные -- пользователю их ни в коем случае показывать нельзя. Но есть и UserFriendly -- исчерпан лимит операций, нет денег на счету и пр. Они понятны и нужны пользователю. Как программист, использующий вашу библиотеку узнает, что сообщение именно ЭТИХ исключений нужно отобразить пользователю?


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

Lib
....
try
{
  ...
}
catch(SqlException se)//не удалось подключиться 
{
  trow new SqlException("Не удалось подключиться к базе данных (можете распарсить текущий эксепшн и сформировать какое угодно сообщение)",se);
}
...


0K>Вы что не поняли? Речь не о системных исключениях. А о UserFriendly, которые содержат важный для пользователя Message.


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

M>>Пользователей за идиотов никто не считает. Сообщить — не значит выдать Exception в том виде, в котором он есть.


0K>Еще раз: контрактные исключения выдвать нельзя. UserFriendly нужно выдать, они содаржат важную информацию. Как вы отличаете исключения которые содержать важную для пользователю информацию от контрактных исключений?


Я поэтому никогда не вывожу пользователю содержание исключения.
Все содержание исключения пишется в лог или как-то обрабатывается. Для пользователя формируется сообщение относительно типа исключения.
Re[3]: Исключения для пользователя и для программиста -- раз
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 12.08.10 08:49
Оценка:
Здравствуйте, 0K, Вы писали:

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


Q>>Практически верно. Но ты смешиваешь в кучу исключения и сообщения исключений. Пользователю может отображаться не тот текст, который пришёл в исключении.


0K>Сообщения есть для пользователей а есть для программистов. И типы исключений, соответственно, должны быть разными.


Кому должны?

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

Для пользовательских исключений все равно будут перехватываться конкретные типы исключений.
Re[3]: Исключения для пользователя и для программиста -- раз
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 12.08.10 08:53
Оценка: +5 :)
Здравствуйте, 0K, Вы писали:

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


M>>Как правило, все исключения поднимаются для разработчиков. Разработчик должен позаботится о том, чтобы пользователь увидел нормальное исключение, а не непонятную, для его мозга, информацию.


0K>Нет. Исключения верхнего уровня в каждой конкретной библиотеке должны быть понятны пользователю.

Кому должны? Если в программе вываливается исключение со стактрейсом, то пользователь приходит в ужас даже несмотря на буковки сообщений. А без стактрейса исключения смысла собственно не имеют, можно и обычными сообщениями обойтись.

0K>К примеру, если в библиотеке для работы с базой данных не возникло исключение -- оно должно быть понятно пользователю: он должен понять в чем проблема и почему не удалось подключиться к базе.

Запомни, все исключения для программистов, что увидит пользователь не должно завязываться на исключения (или другой механизм репортинга ошибок).
Re[6]: Исключения для пользователя и для программиста -- раз
От: 0K Ниоткуда  
Дата: 12.08.10 08:54
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Предлагаю впредь не использовать термин «пользователь», а употреблять «конечный пользователь и «пользователь API».


Давайте проще: разработчик, разработчик библиотеки и пользователь. Деньги откуда идут? От конечного пользователя. Нахрен вообще о программистах говорить?

Q>ApiUserFriendly-исключение, а не EndUserFriendly. Библиотека не знает, что для конечного пользователя будет более friendly: текст на корейском, формат даты ISO-8601, упоминание смещения в файле, начиная с которого пошли некорректные данные, etc.


Это исключение должно быть локализовано, Естественно. Если не локализовано -- другой разговор -- нужно дописать файл локализации к библиотеке.

Q>Библиотека даже не знает, будет ли конечным пользователем человек, или, скажем, сервис без пользовательского интерфейса.


Собственно да. И что вы предлагаете вообще не делать понятных пользователю сообщений об ошибках в библиотеках?

0K>>В том то и дело, что не всегда библиотека знает проблему хуже вызывающего кода (от вызывающего сокрыты детали).


Q>Если библиотека скрывает детали, то это на совести автора библиотеки, он счёл это нужным, таков контракт библиотеки.


Читайте внимательнее: библиотека не всегда знает ХУЖЕ вызывающего кода. Т.е. часто именно библиотека знает настоящие причины возникновения ошибки и может выдать пользователю нужную информацию.

Q>Рассмотрим стандартное исключение FileNotFoundException. Оно содержит ApiUserFriendly-сообщение «Could not find file 'temp_6B8FCD97.xml'.» плюс дополнительное поле ex.FileName, равное «temp_6B8FCD97.xml».

Q>При трансляции конечному пользователю сообщение может превратиться в EndUserFriendly-сообщение, например, в такое: «Нет доступа к файлу с данными о днях рождения ваших друзей.»

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