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

G>Давай более реальный сценарий:
G>Есть форма ввода, например для платежа за счет мобильника. Там поля телефон и сумма. Бизнес слой вываливает эксепшн (UserFriendlyException) с текстом, который говорит почему операция завершилась неуспешно. Например не хватает денег на счете или неверный номер телефона.
G>Ты как программист, которому ниче не надо знать, просто текст выкидываешь на форму и все.
G>А я, как программист, который таки думает о пользователях, забью большой йух на этот эксепшн и буду валидировать поля формы, чтобы по месту сообщить об ошибке.

Я очень хорошо знаком с подобными сервисами и реализовал несколько.

Вы не сможете все валидировать все, там около 500 разных вариантов, почему возникла ошибка. Данные, вводимые пользователем, конечно нужно проверить. Но вы не проверить существует ли номер телефона (не всегда), не заблокирован ли номер телефона, есть ли связь с ЦПП, проводятся ли сейчас платежи. 500 разных ошибок.

G>А потом буду громко ругать авторов бизнес-слоя за то что я не смогу использовать их код в сервисе, потому что на клентской стороне надо будет парсить текст для аналогичного результата.

Не понял, в чем проблема использовать в сервисе? Исключения они ведь обязательно сериализуемые. В чем проблема то?

G>
G>Ты правда считаешь себя умнее программистов в MS?

Они однозначно лучше меня знают свои библиотеки (которую через 20 лет никто и не вспомнит), но далеко не во всех базовых вещах имеют понимание выше моего.

G>И что? Если там простой текст мне на клиенте это никак не поможет.

Поможет. Вы этот текст отображаете пользователю -- ему все становится понятно. Вам как программисту этот текст не нужен, это не ошибка в программе.

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

Это для случая если ошибки по номерам.

0K>>Библиотека работает с финансовым сервисом. Сервис вообще не на .Net написан. Он возвращает описание ошибки в текстовом виде. Что ваша библиотека, строку будет возвращать? Или сообщение со специальным Message?
G>Ну если кто-то профакапил архитектуру до меня, то уже ниче сделать не смогу. Но мы тут обсуждаем как самому не профакапить.

Что плохого в том, что исключения выводятся в нужном для пользователя виде?

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

M>И я твержу уже сколько. Не надо полагаться на сообщение исключения!!! формируйте своё на основании типа и другой информации исключения. Вам никто не гарантирует, что в e.Message сторонней библиотеки, даже как бы предназначенной для показа пользователю будет лежать то, что вам нужно.

Автор библиотеки это должен гарантировать. И такие исключения нужно наследовать от специального системного класса.

Зачем делать двойную работу??? Почему каждый пользователь библиотеки должен расшифровывать тысячи вариантов ошибок?

Давайте практический смысл.

0K>>При локализации вы меняете язык. Можете кое-чего добавить. А что вам еще нужно?
M>Ну тогда вам нужно будет менять все во всех файлах ресурсов. 10 библиотек с ресурсами, полезете во все 10 библиотек.

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

M>Не проще ли на уровне приложения создать 1 файл ресурсов, который бы на одинаковые типы ошибок выдавал одинаковые сообщения?

Нет, не проще. Это работа программиста и стоит дороже. Переводчик сделает все качественнее, быстрее и дешевле.

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

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

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

G>>Давай более реальный сценарий:
G>>Есть форма ввода, например для платежа за счет мобильника. Там поля телефон и сумма. Бизнес слой вываливает эксепшн (UserFriendlyException) с текстом, который говорит почему операция завершилась неуспешно. Например не хватает денег на счете или неверный номер телефона.
G>>Ты как программист, которому ниче не надо знать, просто текст выкидываешь на форму и все.
G>>А я, как программист, который таки думает о пользователях, забью большой йух на этот эксепшн и буду валидировать поля формы, чтобы по месту сообщить об ошибке.

0K>Я очень хорошо знаком с подобными сервисами и реализовал несколько.

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

0K>Данные, вводимые пользователем, конечно нужно проверить. Но вы не проверить существует ли номер телефона (не всегда), не заблокирован ли номер телефона, есть ли связь с ЦПП, проводятся ли сейчас платежи. 500 разных ошибок.
Ну и все они относятся к этому самому телефону и выводиться должны именно там.

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

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

G>>
G>>Ты правда считаешь себя умнее программистов в MS?
0K>Они однозначно лучше меня знают свои библиотеки (которую через 20 лет никто и не вспомнит), но далеко не во всех базовых вещах имеют понимание выше моего.
То есть ты таки считаешь себя умнее программистов MS. Говорит о многом

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


0K>>>Библиотека работает с финансовым сервисом. Сервис вообще не на .Net написан. Он возвращает описание ошибки в текстовом виде. Что ваша библиотека, строку будет возвращать? Или сообщение со специальным Message?
G>>Ну если кто-то профакапил архитектуру до меня, то уже ниче сделать не смогу. Но мы тут обсуждаем как самому не профакапить.
0K>Что плохого в том, что исключения выводятся в нужном для пользователя виде?
Ну как тебе сказать...
Пользователю не нужны эти самые исключения, ему нужно свою работу делать. А исключения нужны тебе, чтобы не протерять ошибку.
Вот тут есть проблема, ошибка должна быть обнаружена как можно раньше и выброшена в виде исключения, а сообщение пользователю нужно формировать как можно позже, чтобы удобно было. Вот тут и возникает проблема.

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

G>Пофигу, не надо проблемы валить на пользователя.

Как раз надо. Если пользователь узнает что номер заблокирован -- он его пополнит на 25 грн., а не на 5 (чтобы разбокировали).

Не считайте пользователей идиотами. Они прекрасно поймут текст ошибки в 80% случаев он им будет полезен.

G>Особенно ситуация усугубляется если полей ввода много. Или например два поля с телефонами, а к тебе из глубин бизнес-слоя прилетает эксепшен "телефон заблокирован".

Нет. Не не UserFriendlyException. Нужно указать какой именно номер и по какой причине. Тот кто делает библиотеку -- лучше вас знает в каком виде нужно выдать исключения пользователю.

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

Читал, и что?

G>То есть ты таки считаешь себя умнее программистов MS. Говорит о многом

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

0K>>Поможет. Вы этот текст отображаете пользователю -- ему все становится понятно. Вам как программисту этот текст не нужен, это не ошибка в программе.
G> Пример с двумя полями телефонов я уже привел.

Просто вы привели текст, который никогда не включат в UserFriendlyException.

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

Нет. Вы ПЕРЕПУТАЛИ исключения, вызываемые ошибками в коде и исключения, предназначенные для вывода информации пользователю. Не путайтесь, это разные виды исключений. Не все исключения нужно логировать.

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

Это не ошибка с т.з. работы программы. Это просто ошибка в бизнес-процессе. Логировать ее не нужно и реакции на нее не нужно. Она нужна только пользователю. Показать ее нужно сразу, т.к. чем бысрее пользователь узнает -- тем быстрее решит проблему.

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

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

G>>Пофигу, не надо проблемы валить на пользователя.

0K>Как раз надо. Если пользователь узнает что номер заблокирован -- он его пополнит на 25 грн., а не на 5 (чтобы разбокировали).
Разговор не об этом.

0K>Не считайте пользователей идиотами. Они прекрасно поймут текст ошибки в 80% случаев он им будет полезен.
Я не считаю пользователя идиотами, я стараюсь удобно делать.
Еще раз, в случае более 5 полей сообщение об ошибке надо привязать к конкретному полю. С эксепшенами так не выйдет.

G>>Особенно ситуация усугубляется если полей ввода много. Или например два поля с телефонами, а к тебе из глубин бизнес-слоя прилетает эксепшен "телефон заблокирован".

0K>Нет. Не не UserFriendlyException. Нужно указать какой именно номер и по какой причине. Тот кто делает библиотеку -- лучше вас знает в каком виде нужно выдать исключения пользователю.
Сильное завявление, обосновать сможешь?
Учитывая что тот кто делает библиотеку даже не может предполагать будет ли пользователь.

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

G>>То есть ты таки считаешь себя умнее программистов MS. Говорит о многом

0K>А вы считаете себя глупее?
Конечно, поэтому изучаю много.

0K>Как это вообще можно измерять?
Не можешь измерить — считай себя глупее.



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



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

0K>Нет. Вы ПЕРЕПУТАЛИ исключения, вызываемые ошибками в коде и исключения, предназначенные для вывода информации пользователю. Не путайтесь, это разные виды исключений. Не все исключения нужно логировать.
Нету исключений для вывода информации пользователю. Причину я описал: исключения возникают в глубине кода, а отображать сообщения надо "снаружи".

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

0K>Это не ошибка с т.з. работы программы. Это просто ошибка в бизнес-процессе. Логировать ее не нужно и реакции на нее не нужно. Она нужна только пользователю. Показать ее нужно сразу, т.к. чем бысрее пользователь узнает -- тем быстрее решит проблему.
Ну а причем тут исключения?

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

0K>Здравсти! MSDN изредка почитывайте. Локализация сообщений об ошибках -- обязательное требование. Почему, по вашему, MS сами локализуют сообщения об ошибках в своей .Net платформе?

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

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

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

M>>И я твержу уже сколько. Не надо полагаться на сообщение исключения!!! формируйте своё на основании типа и другой информации исключения. Вам никто не гарантирует, что в e.Message сторонней библиотеки, даже как бы предназначенной для показа пользователю будет лежать то, что вам нужно.

0K>Автор библиотеки это должен гарантировать. И такие исключения нужно наследовать от специального системного класса.

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

0K>Зачем делать двойную работу??? Почему каждый пользователь библиотеки должен расшифровывать тысячи вариантов ошибок?

ситуация простая. Приведу пример.

        public class Lib2
         {
             void Foo()
             {
                 int val1;
                 int val2;
                 int val3;

                 try
                 {
                     val1 = Lib1.GetVal1();
                 }
                 catch (DivideByZeroException ex)
                 {
                     //какая-то обработка ошибки
                     ...
                     val2 = Lib1.GetVal2();
                 }
                 catch (ArgumentException aex)
                 {
                     //какая-то обработка ошибки
                     ...
                     val3 = Lib1.GetVal3();
                 }
                 catch(CustomException ce)
                 {
                     //В зависимости от кода ошибки сделать какие либо действия
                     if(ce.ErrorType == ErrorType.One) 
                     //....
                     else if(ce.ErrorType == ErrorType.Two)
                     //....
                 }
                 catch(SqlException se)
                 {
                     //Не удалось получить данные с определенного сервера
                     if(se.Server == "ServerName") 
                     //Получаем данные с другого сервера
                     else if(se.Server == "ServerName1")
                     //Поднимаем исключение наверх
                 }
             }
         }

И так можно разворачивать сценарий как угодно. И разработчику библиотеки невозможно предсказать, как и в каких сценариях будет использоваться его библиотека.
На разные типы ошибок могут быть разные сценарии.
Разработчик использует вашу библиотеку. Зачем ему FriendlyMessage? У него по бизнес-логике должно формироваться другое сообщение или другие сценарии.


0K>>>При локализации вы меняете язык. Можете кое-чего добавить. А что вам еще нужно?
M>>Ну тогда вам нужно будет менять все во всех файлах ресурсов. 10 библиотек с ресурсами, полезете во все 10 библиотек.

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

M>>Не проще ли на уровне приложения создать 1 файл ресурсов, который бы на одинаковые типы ошибок выдавал одинаковые сообщения?

0K>Нет, не проще. Это работа программиста и стоит дороже. Переводчик сделает все качественнее, быстрее и дешевле.

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

0K>Зачем каждый дожен расшифровывать коды ошибок библиотеки, если можно один раз в самой библиотеке создать файл ресурсов с корректными сообщениями об ошибках? Зачем делать дурную работу?

Да потому что на каждый тип/код ошибки может быть свой сценарий работы приложения. Задумайтесь об этом.

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

G>Зачем номера, есть же типы

G>

G>try
G>{
G>//...
G>}
G>catch(Ex1 e1)
G>{
G>//...
G>}
G>catch(Ex2 e2)
G>{
G>//...
G>}

G>

И так 200 рвз:

G>Все что ты пытаешься придумать было продумано до тебя и гораздо тщательнее, если не пошло "в массы", значит на это есть свои причины.

Где и кем? Ссылка?

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

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

G>>Зачем номера, есть же типы

G>>

G>>try
G>>{
G>>//...
G>>}
G>>catch(Ex1 e1)
G>>{
G>>//...
G>>}
G>>catch(Ex2 e2)
G>>{
G>>//...
G>>}

G>>

0K>И так 200 рвз:
Именно поэтому исключениями в UI мало пользуются.

G>>Все что ты пытаешься придумать было продумано до тебя и гораздо тщательнее, если не пошло "в массы", значит на это есть свои причины.
0K>Где и кем? Ссылка?
Framework desingn guidelines и блоги разработчиков. Ссылки не собираю, ищи сам.

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

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

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

Хм... а что, нет единого обработчика всех исключений, вроде как Application.OnException в Delphi? Там, в одном месте, собственно говоря, и должна выполняться вся работа по преобразованию исключений в понятные сообщения.

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

M>Хм... а что, нет единого обработчика всех исключений, вроде как Application.OnException в Delphi? Там, в одном месте, собственно говоря, и должна выполняться вся работа по преобразованию исключений в понятные сообщения.

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

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

M>Хм... а что, нет единого обработчика всех исключений, вроде как Application.OnException в Delphi? Там, в одном месте, собственно говоря, и должна выполняться вся работа по преобразованию исключений в понятные сообщения.

Пришло тебе в глобальный обработчик исключение типа System.InvalidOperationException с сообщением «Sequence contains no elements». Давай, преобразуй исключение в понятное сообщение.

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

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

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

Откровенная ерунда.

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

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

В этой и соседних ветках я насчитал от тебя не менее пяти фраз (адресованных разным собеседникам) типа «т.е. вы предлагаете <и далее свои фантазии, желательно, легко опровергаемые>.» Раздражает. Например, было: «Т.е. вы предлагаете вернуться к кодам ошибок? (И ещё четыре вопросительных знака.)» То, что ты предлагаешь — оно и есть, только имеет тип не int, а string, и называется не код ошибки, а сообщение исключения.

Информация об ошибке передаётся:
1) В типе исключения. Позволяет сепарировать исключения в момент ловли.
2) В полях исключения. Позволяет восстанавливать контекст исключения, состояние возникновение ошибки.
3) В тексте сообщения. В случае usage exception'ов содержит указание, как изменить код, чтобы избежать выброс исключения; ориентировано на пользователя API. В случае runtime-исключения содержит сообщение о причинах исключения в меру своей осведомлённости; ориентировано на пользователя API или конечного пользователя. В подавляющем большинстве случаев это сообщение нельзя отображать в UI — в нём либо содержатся избыточные детали, либо, наоборот, отсутствует контекст. Например, стандартные коллекции не знают, что работают со списком пользовательских аккаунтов, их сообщения по простоте душевной оперируют терминами «элемент коллекции».

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

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

Вот ты приводил пример, когда у тебя стописят разных ошибок, и все возвращаются через один класс EndUserFriendly-исключения, отличаясь только сообщениями. Отлично, ты просто выводишь месседж. А завтра начальник говорит тебе: а в случае, если тип ошибки «Номер +755щ2713141 имеет ниверный формат.», выдавать не сообщение с орфографической ошибкой, а окошко ввода нового номера. И у тебя начнётся ад. Тебе придётся сепарировать исключения по тексту сообщения. Да не просто равенством, а парсингом. Да учесть все возможные (как существующие, так и будущие) локализации. Это намного, намного хуже кодов ошибок! Ты проклянёшь автора библиотеки, который взял на себя смелость вместо пользователя API решать, что увидит конечный пользователь.

Q>>Рассмотрим стандартное исключение FileNotFoundException. Оно содержит ApiUserFriendly-сообщение «Could not find file 'temp_6B8FCD97.xml'.» плюс дополнительное поле ex.FileName, равное «temp_6B8FCD97.xml».
Q>>При трансляции конечному пользователю сообщение может превратиться в EndUserFriendly-сообщение, например, в такое: «Нет доступа к файлу с данными о днях рождения ваших друзей.»

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

Если нужно — легко. В классе FileNotFoundException содержится поле ex.FileName. Мне не важно, что в поле ex.Message содержится «Файл „filename.xml“ не найден». Я всегда смогу (и по умолчанию — буду) формировать своё сообщение, допустим, «Проверьте, пожалуйста, наличие файла {0}.»; и подставлю ex.FileName, а не выпарсенное между кавычками название файла.

Реквестирую неудаление этой темы, несмотря на соответствующую пометку.

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

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

Q>Откровенная ерунда.

Как раз не ерунда. На .Net большая часть публичных приложений создана для разработчиков. Каждый лепит свой велосипед. Разработчик -- это строитель, а не пользователь.

Q>То, что ты предлагаешь — оно и есть, только имеет тип не int, а string, и называется не код ошибки, а сообщение исключения.

Вы вообще не поняли о чем речь. Вообще нуль. Читали читали -- и не поняли.

Q>Информация об ошибке передаётся:
Q>1) В типе исключения. Позволяет сепарировать исключения в момент ловли.

А я разве не об этом же? Тип исключения + структуризация: наследование от UserFriendlyException.

Q>2) В полях исключения. Позволяет восстанавливать контекст исключения, состояние возникновение ошибки.
Q>3) В тексте сообщения. В случае usage exception'ов содержит указание, как изменить код, чтобы избежать выброс исключения;

Да поймите же вы! Не нужно менять код для этого исключения! Оно ожидаемо. Нет ошибки в коде. Сколько можно повторять???

Не нужно его логировать. Не нужно о нем знать разработчику и беспокоить его лишний раз этим исключением. Оно только для пользователя!

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

Здесь просто. Данные, которые вводит пользователь обрабатываем сразу. Исключения не генерируются. Кроме того, UserFriendly может содержать и Enum с типом. Об этом я выше писал.

Q>И у тебя начнётся ад. Тебе придётся сепарировать исключения по тексту сообщения. Да не просто равенством, а парсингом. Да учесть все возможные (как существующие, так и будущие) локализации. Это намного, намного хуже кодов ошибок! Ты проклянёшь автора библиотеки, который взял на себя смелость вместо пользователя API решать, что увидит конечный пользователь.

Ничто не мешает добавить Enum с типом. Выше я писал об этом.

А вы будуте для каждого использования библиотеки вручную расшифровывать все варианты этого Enum. Я же предлагаю сделать эту расшифровку в библиотеке в Message.

Q>Если нужно — легко. В классе FileNotFoundException содержится поле ex.FileName. Мне не важно, что в поле ex.Message содержится «Файл „filename.xml“ не найден». Я всегда смогу (и по умолчанию — буду) формировать своё сообщение, допустим, «Проверьте, пожалуйста, наличие файла {0}.»; и подставлю ex.FileName, а не выпарсенное между кавычками название файла.

А нахрена? Вы знаете, что вы допустили ошибку сейчас? В данном случае слово пожалуйста не уместно и пользователь будет чувствовать себя неловко. Оставьте все как есть, там все хорошо без ваших стараний сделано.

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

Q>>Информация об ошибке передаётся:
Q>>1) В типе исключения. Позволяет сепарировать исключения в момент ловли.

0K>А я разве не об этом же? Тип исключения + структуризация: наследование от UserFriendlyException.

Нет, ты ровно о противоположном. Ты предлагаешь делать

try
{
 //code
}
catch(UserFriendlyException e)
{
  ReportToUser(e.Message)
}

Те фактически забить на тип исключения, а тупо передавать одну строку. Или строку + код ошибки.

Q>>2) В полях исключения. Позволяет восстанавливать контекст исключения, состояние возникновение ошибки.
Q>>3) В тексте сообщения. В случае usage exception'ов содержит указание, как изменить код, чтобы избежать выброс исключения;

0K>Да поймите же вы! Не нужно менять код для этого исключения! Оно ожидаемо. Нет ошибки в коде. Сколько можно повторять???
Вопрос в том где оно ожидаемо? В месте выбрасывания оно как раз не ожидаемо, оно ожидаемо где-то ближе к UI, но там уже слишком поздно бросать исключения.

0K>Не нужно его логировать. Не нужно о нем знать разработчику и беспокоить его лишний раз этим исключением. Оно только для пользователя!
Ну давай расскажи все таки как победить такую ситуацию:
Есть два поля ввода телефона на форме, каждый из них одинаково обрабатывается логикой приложения. Где-то в глубине может выпасть исключение, типа "невозможно определить оператора". Как ты сделаешь выбрасывание исключения в данном случае и отображения ошибки пользователю.

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

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

0K>Кроме того, UserFriendly может содержать и Enum с типом. Об этом я выше писал.
То есть получили они класс UserFriendlyException с Enum_ом (кодом ошибки), потрясающе. Все умы, которые разрабатывали исключения, должны непременно посыпать голову пеплом.

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

Q>Пришло тебе в глобальный обработчик исключение типа System.InvalidOperationException с сообщением «Sequence contains no elements». Давай, преобразуй исключение в понятное сообщение.

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

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

Q>>Пришло тебе в глобальный обработчик исключение типа System.InvalidOperationException с сообщением «Sequence contains no elements». Давай, преобразуй исключение в понятное сообщение.

M>Внутренняя ошибка программы, опишите выполненные вами действия и отправьте отчет разработчикам. И кнопка "Отправить отчет"

Мне больше по нраву другой вариант. Перехватываю исключение не в глобальном обработчике, а как только оно поднимается до уровня, где хватает данных о контексте. Тогда я сформирую сообщение «К этому отделу не приписан ни один сотрудник.», проброшу свой тип исключения, определяемый в моей бизнес-логике, а presentation layer доблестно отобразит понятное пользователю сообщение. Все рады, довольны, багрепорты разработчику не шлют, профит!

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

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

M>>Хм... а что, нет единого обработчика всех исключений, вроде как Application.OnException в Delphi? Там, в одном месте, собственно говоря, и должна выполняться вся работа по преобразованию исключений в понятные сообщения.

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

Разработчик библиотеки в принципе не может с этим справиться, потому что ему неизвестен ни предполагаемый уровень пользователя (админ, рядовой пользователь), ни страница справки, которая должна будет подниматься, ни то, как данная ошибка может быть устранена/обойдена средствами программы, ни в результате какого глобального действия возникла ошибка. Будет испорченный телефон.

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

Но если такая обработка централизована, это удобно. Надо улучшить сообщение об ошибке --- знаешь где

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

Q>Мне больше по нраву другой вариант. Перехватываю исключение не в глобальном обработчике, а как только оно поднимается до уровня, где хватает данных о контексте. Тогда я сформирую сообщение «К этому отделу не приписан ни один сотрудник.», проброшу свой тип исключения, определяемый в моей бизнес-логике, а presentation layer доблестно отобразит понятное пользователю сообщение. Все рады, довольны, багрепорты разработчику не шлют, профит!

А я такое поведение запрещал? Это вообще штатная ситуация, которая проверяется условием и последующим бросанием исключения.