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

_FR>Поэтому ничего страшного в том, что бы показать пользователю текст прилетевшего исключение нет: если уж програмист не знает что делать, может и пользователь сможет исправить ситуацию лучше.

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

_FR>Поэтому "заморачиваться с локализацией текстов сообщений" очень надо. А ужд програмист сам решит, что ему с этой локализацией делать: повеситься или показывать пользователю

Правильно.

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

0K>>Куда вам скинуть ссылку на книгу Рихтера?
G>А ты его сам-то читал?

Да. Прочитал все об исключениях 2 раза -- ничего нового не узнал. Но Рихтер меня утешил тем, что увидел те же проблемы что и я увидел.

0K>>Там написано как делать глобальный обработчик непредвиденных исключений.
G>Где? Номер страницы.

Под рукой сейчас 2-е издание на русском. Стр. 366-374 (если у вас другое издание -- найдете).

G>CLR via C#, 3rd edition, страница 500.

Дорогой вы мой! Там же о библиотеках сказано.

G>Эта краткая цитата опровергает тонны твоего флейма на форуме.

Если бы вы еще поняли о чем там пишут.

0K>>Нужно написать на языке понятном для пользователя что произошла непредвиденная ошибка.
G>Датыче?
G>То есть надо предусмотреть локализацию на несколько языков чтоли? Это оправдано для простого сайта?

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

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

_FR>Поэтому ничего страшного в том, что бы показать пользователю текст прилетевшего исключение нет: если уж програмист не знает что делать, может и пользователь сможет исправить ситуацию лучше.

А еще лучше при этом завершить приложение\текущую операцию.

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

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

_FR>>Поэтому ничего страшного в том, что бы показать пользователю текст прилетевшего исключение нет: если уж програмист не знает что делать, может и пользователь сможет исправить ситуацию лучше.

0K>Ну хоть один авторитет открыто поддержал то что я давно пытаюсь доказать.
Нет дорогой, ты пытаешьсо доказать что нужны типы исключений предназначенные только для показа сообщения пользователю. А это в корне неверно.
У тебя вообще с логикой проблемы. Ты считаешь что утверждения "Если А, то Б" и "Если Б, то А" эквивалентны, а это не так.

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


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

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

_FR>>Поэтому ничего страшного в том, что бы показать пользователю текст прилетевшего исключение нет: если уж програмист не знает что делать, может и пользователь сможет исправить ситуацию лучше.

G>А еще лучше при этом завершить приложение\текущую операцию.

Зачем? Можете на вскидку сзазать, по каким причинам при вызове SqlCommand.Execute<…> может прилететь SqlException? Как нужно обработать отсутствие соединения, отсутствие процедуры, недостаток прав или какую-то проблему в самой процедуре? И почему следует закрывать приложение при этом? Если сеть оборвалась, то и нечего дальше работать?

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

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

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

0K>>>Там написано как делать глобальный обработчик непредвиденных исключений.
G>>Где? Номер страницы.
0K>Под рукой сейчас 2-е издание на русском. Стр. 366-374 (если у вас другое издание -- найдете).
Да просто приведи текст и название раздела, в новой редакции найдем.

G>>CLR via C#, 3rd edition, страница 500.

0K>Дорогой вы мой! Там же о библиотеках сказано.

Перевожу

Разработчики библиотек не должны даже думать о неперехваченных исключениях.
Только разработчики приложений должны беспокоиться о неперехваченных исключениях,
и приложение должно иметь политику обработки необработанных исключений.
Microsoft рекомендует принимать политику по-умолчанию для CLR

Последняя фраза таки означает что не надо писать глобальный обработчик исключений.
Дошло?

G>>Эта краткая цитата опровергает тонны твоего флейма на форуме.
0K>Если бы вы еще поняли о чем там пишут.
Если бы ты сам понял что доказать пытаешься
А то кажется что единственная твоя цель — доказать что ты круче всех, в том числе пацанов из конторы на букву М.

0K>>>Нужно написать на языке понятном для пользователя что произошла непредвиденная ошибка.
G>>Датыче?
G>>То есть надо предусмотреть локализацию на несколько языков чтоли? Это оправдано для простого сайта?

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

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

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

_FR>>>Поэтому ничего страшного в том, что бы показать пользователю текст прилетевшего исключение нет: если уж програмист не знает что делать, может и пользователь сможет исправить ситуацию лучше.

G>>А еще лучше при этом завершить приложение\текущую операцию.

_FR>Зачем? Можете на вскидку сзазать, по каким причинам при вызове SqlCommand.Execute<…> может прилететь SqlException?
Не могу, поэтому просто не буду обрабатывать SqlException, что приведет к завершению операции или приложения.
Могу сказать только ситуацию при которой можно продолжать работу после SqlException: нарушение уникальности.

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

_FR>Если сеть оборвалась, то и нечего дальше работать?
Да, есть другие варианты? Если ocassionaly conected приложение, то там сначала все складывается в локальную базу и подобно ошибки не будет.

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

_FR>>>>Поэтому ничего страшного в том, что бы показать пользователю текст прилетевшего исключение нет: если уж програмист не знает что делать, может и пользователь сможет исправить ситуацию лучше.

G>>>А еще лучше при этом завершить приложение\текущую операцию.

_FR>>Зачем? Можете на вскидку сзазать, по каким причинам при вызове SqlCommand.Execute<…> может прилететь SqlException?
G>Не могу, поэтому просто не буду обрабатывать SqlException, что приведет к завершению операции или приложения.
G>Могу сказать только ситуацию при которой можно продолжать работу после SqlException: нарушение уникальности.

Покажите пожалуйста алгоритм, который позволит из, например, SqlException определить, что произошло именнол нарушение уникальности. А как же быть с другими ошибками, как то нарушение ссылочной целостности?

_FR>>Как нужно обработать отсутствие соединения, отсутствие процедуры, недостаток прав или какую-то проблему в самой процедуре? И почему следует закрывать приложение при этом?
G>Как минимум прервать текущую операцию,

Можно и прервать, но это к делу не относится.

G>а в некоторых случаях и закрыть приложение (например если ошибка при старте).

А если не на старте? Вы согласны, что коментарий

А еще лучше при этом завершить приложение\текущую операцию.

зачастую не уместен?

_FR>>Если сеть оборвалась, то и нечего дальше работать?
G>Да, есть другие варианты?

Конечно.

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

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

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

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

_FR>>>>>Поэтому ничего страшного в том, что бы показать пользователю текст прилетевшего исключение нет: если уж програмист не знает что делать, может и пользователь сможет исправить ситуацию лучше.

G>>>>А еще лучше при этом завершить приложение\текущую операцию.

_FR>>>Зачем? Можете на вскидку сзазать, по каким причинам при вызове SqlCommand.Execute<…> может прилететь SqlException?
G>>Не могу, поэтому просто не буду обрабатывать SqlException, что приведет к завершению операции или приложения.
G>>Могу сказать только ситуацию при которой можно продолжать работу после SqlException: нарушение уникальности.

_FR>Покажите пожалуйста алгоритм, который позволит из, например, SqlException определить, что произошло именнол нарушение уникальности.
Внтури SqlException есть SqlError, у которого есть Number. Этот Number в точности определяет тип ошибки.
А еще лучше написать запрос, который не упадет в случае нарушения, а потом анализировать affected rows.

_FR>А как же быть с другими ошибками, как то нарушение ссылочной целостности?
А как я его могу исправить? Если внешний ключ, который вводится не вручную, а выбирается из списка в интерфейсе, вдруг оказался невалидным, то единственное что я могу сделать — сказать "ололо кто-то поменял данные и надо перезапустить операцию".


_FR>>>Как нужно обработать отсутствие соединения, отсутствие процедуры, недостаток прав или какую-то проблему в самой процедуре? И почему следует закрывать приложение при этом?
G>>Как минимум прервать текущую операцию,

_FR>Можно и прервать, но это к делу не относится.
Как раз относится.

G>>а в некоторых случаях и закрыть приложение (например если ошибка при старте).

_FR>А если не на старте?
Тогда прервать операцию.

_FR>Вы согласны, что коментарий

А еще лучше при этом завершить приложение\текущую операцию.

зачастую не уместен?
Нет, это зачастую самое лучшее решение.
не забывай что большинство exception пользователь видит если в программе явно баг. А если пользователь испытывает неудобства из-за этого, то баг будет исправлен быстрее.

_FR>>>Если сеть оборвалась, то и нечего дальше работать?
G>>Да, есть другие варианты?
_FR>Конечно.
Например?

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

_FR>А если это Excel, который замапен на некую внешнюю БД? Если он будет закрываться с необработанной ошибкой, это будет совсем не то, чего ждёт пользователь.
Он как раз ocassionaly conected. Данные хранит локально и синхронизирует с БД.

_FR>Как и в большинстве задач.
Нет. Как раз в большинстве задач нарушение связи с БД означает невозможность дальнейшей работы.

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

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

То же самое могу сказать про вас. Читаете между строк и только то что вам нравится. Ниже я это докажу.

G>Да просто приведи текст и название раздела, в новой редакции найдем.

Так и называется: работа с unhandled exception (отдельная статья для WinForm, WebForm и пр.).

G>Перевожу

G>

G>Разработчики библиотек не должны даже думать о неперехваченных исключениях.
G>Только разработчики приложений должны беспокоиться о неперехваченных исключениях,
G>и приложение должно иметь политику обработки необработанных исключений.
G>Microsoft рекомендует принимать политику по-умолчанию для CLR

G>Последняя фраза таки означает что не надо писать глобальный обработчик исключений.

Вот это то о чем я говорил. Первые 2 фразы вы не увидели.

разработчики приложений должны беспокоиться о неперехваченных исключениях
разработчики приложений должны беспокоиться о неперехваченных исключениях
разработчики приложений должны беспокоиться о неперехваченных исключениях

Дошло? Или вы называете заботой -- оставить не вполне ясное окошко с текстом ошибки? Нафига?

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

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

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

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

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

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

G>>Да просто приведи текст и название раздела, в новой редакции найдем.

0K>Так и называется: работа с unhandled exception (отдельная статья для WinForm, WebForm и пр.).
В тертьей редакции нет, устарело наверное

G>>Перевожу

G>>

G>>Разработчики библиотек не должны даже думать о неперехваченных исключениях.
G>>Только разработчики приложений должны беспокоиться о неперехваченных исключениях,
G>>и приложение должно иметь политику обработки необработанных исключений.
G>>Microsoft рекомендует принимать политику по-умолчанию для CLR

G>>Последняя фраза таки означает что не надо писать глобальный обработчик исключений.

0K>Вот это то о чем я говорил. Первые 2 фразы вы не увидели.

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

0K>Дошло? Или вы называете заботой -- оставить не вполне ясное окошко с текстом ошибки? Нафига?
См выше.
Прочитай ты уже наконец рихтера внимательно и Framework Design Guidelines, может поймешь все таки.
И уж точно прекращай себя считать умнее всех.

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

0K>Если исключение предназначено исключительно для разработчика -- пусть лучше увидит его на английском. Глобализация, английский все в школах учат -- поймет что это вы чего-то недоработали.
Ага, будут у него попеременно "Object reference is not set..." и "Пустая последовательность..." круто!

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

_FR>>>>>>Поэтому ничего страшного в том, что бы показать пользователю текст прилетевшего исключение нет: если уж програмист не знает что делать, может и пользователь сможет исправить ситуацию лучше.
G>>>>>А еще лучше при этом завершить приложение\текущую операцию.
_FR>>>>Зачем? Можете на вскидку сзазать, по каким причинам при вызове SqlCommand.Execute<…> может прилететь SqlException?
G>>>Не могу, поэтому просто не буду обрабатывать SqlException, что приведет к завершению операции или приложения.
G>>>Могу сказать только ситуацию при которой можно продолжать работу после SqlException: нарушение уникальности.

_FR>>Покажите пожалуйста алгоритм, который позволит из, например, SqlException определить, что произошло именнол нарушение уникальности.
G>Внтури SqlException есть SqlError, у которого есть Number. Этот Number в точности определяет тип ошибки.

Покажите пожалуйста конкретный пример, ладно? А то как зделать знают все, но никто ничего никогда не делал

G>А еще лучше написать запрос, который не упадет в случае нарушения, а потом анализировать affected rows.

Ещё лучше — или не выдавать необдуманных фраз или признавать их неправоту, чем придумывать или советовать, что лучше. Я сам могу решать, что лучше и не авторитетом давить надо ("лучше это"), а логикой. В данном случае быть может так, что запрос пишет неизвестный мне програмист и какие могут быть в нём ошибки не неизвестно. Так следует делать даже когда "неизвестный програмист" сидит рядом (даже на том же стуле за тем же монитором что и вы) — потому что чем меньше неконтролируемых договорённостей, тем надёжнее. Контракт "запрос ни при каких обстоятельствах не завершится неудачей" не сможет обеспечить никто, даже говоря о запросе вида "SELECT @@VERSION;".

_FR>>А как же быть с другими ошибками, как то нарушение ссылочной целостности?
G>А как я его могу исправить? Если внешний ключ, который вводится не вручную, а выбирается из списка в интерфейсе, вдруг оказался невалидным, то единственное что я могу сделать — сказать "ололо кто-то поменял данные и надо перезапустить операцию".

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

_FR>>>>Как нужно обработать отсутствие соединения, отсутствие процедуры, недостаток прав или какую-то проблему в самой процедуре? И почему следует закрывать приложение при этом?
G>>>Как минимум прервать текущую операцию,
_FR>>Можно и прервать, но это к делу не относится.
G>Как раз относится.

Как же? Какая разница в контексте данного вопроса — "прервать", "оправить письмо" или "отформатировать жёсткий диск"

G>>>а в некоторых случаях и закрыть приложение (например если ошибка при старте).
_FR>>А если не на старте?
G>Тогда прервать операцию.

И всё? ничего не сообщая пользователю?

_FR>>Вы согласны, что коментарий

А еще лучше при этом завершить приложение\текущую операцию.

зачастую не уместен?
G>Нет, это зачастую самое лучшее решение.
G>не забывай что большинство exception пользователь видит если в программе явно баг.

Не могу забыть, ибо не согласен с этим.

G>А если пользователь испытывает неудобства из-за этого, то баг будет исправлен быстрее.

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

_FR>>>>Если сеть оборвалась, то и нечего дальше работать?
G>>>Да, есть другие варианты?
_FR>>Конечно.
G>Например?

Показать пользователю текст исключения с кнопкой ОК например и подождать что он будет делать дольше — закроет приложение и пойдёт пить чай или будет устранять — например запустит сервис, проверит, что сетевой кабель подключён и прочее.

G>>>Если ocassionaly conected приложение, то там сначала все складывается в локальную базу и подобно ошибки не будет.
_FR>>А если это Excel, который замапен на некую внешнюю БД? Если он будет закрываться с необработанной ошибкой, это будет совсем не то, чего ждёт пользователь.
G>Он как раз ocassionaly conected. Данные хранит локально и синхронизирует с БД.

В контексте данного обсуждения важно то, что при невозможности обновить данные эксель показывает такое вот сообщение:

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

_FR>>Как и в большинстве задач.
G>Нет. Как раз в большинстве задач нарушение связи с БД означает невозможность дальнейшей работы.

Во-первых, временную. Во-вторых, легко устраняемую на стороне клиента. Поэтому аварийно закрывать приложение в данном случае (а я могу придумать и сотни других) не нужно.

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

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

Да, именно это можно выделить как ключевые слова (по поему мнению). Даже если принять их на веру (мне не нравится слово "большинство") то это прямо означает, что

А еще лучше при этом завершить приложение\текущую операцию.

не верно, потому что нет уточнения про "меньшенство", которое имеет место быть в "не забывай что большинство exception …".

G>не забывай что большинство exception пользователь видит если в программе явно баг.

Тут от самого исключения очень много зависит. Если речь про NullReferenceException, ArgumentException или InvalidOperationException, то это однозначно баг. Если речь про MyBussinessLogicException, прилетевшую с сервера при выполнении сложной операции? На клиента прикажите добавлять информацию по всевозможным кодам ошибки? (С сиквелам указанная мной выше "проблема" того же разряда).

Далается же так: сервер тужится, что-то делает, не вышло — сообщает об этом. (может быть или системная или логическая ошибка, систьемную можно не показывать, я о логической). Протягивать ошибку не как исключение а как некий OperationResult накладно (суть: тот же код ошибки со всеми вытекающими и разницы некакой от исключения). Поэтому слова о том, что текст некоторых исключений более чем предназначен для глаз конечного пользователя — отображать суть. покажите-ка мне пример какого-нить аналога динк-пада, который падает при возникновении DbException

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

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

_FR>>>>>>>Поэтому ничего страшного в том, что бы показать пользователю текст прилетевшего исключение нет: если уж програмист не знает что делать, может и пользователь сможет исправить ситуацию лучше.
G>>>>>>А еще лучше при этом завершить приложение\текущую операцию.
_FR>>>>>Зачем? Можете на вскидку сзазать, по каким причинам при вызове SqlCommand.Execute<…> может прилететь SqlException?
G>>>>Не могу, поэтому просто не буду обрабатывать SqlException, что приведет к завершению операции или приложения.
G>>>>Могу сказать только ситуацию при которой можно продолжать работу после SqlException: нарушение уникальности.

_FR>>>Покажите пожалуйста алгоритм, который позволит из, например, SqlException определить, что произошло именнол нарушение уникальности.
G>>Внтури SqlException есть SqlError, у которого есть Number. Этот Number в точности определяет тип ошибки.

_FR>Покажите пожалуйста конкретный пример, ладно? А то как зделать знают все, но никто ничего никогда не делал \
Для SQL Server код нарушения UNIQUE CONSTRAINT — 2627

try
{

}
catch (SqlException ex)
{
    var hasUnhandledErrors = false;
    foreach (SqlError error in ex.Errors)
    {
        if (error.Number == 2627)
        {
            HandleError(error);
        }
        else
        {
            hasUnhandledErrors = true;
        }
    }
    if (hasUnhandledErrors)
    {
        throw;
    }
}

G>>А еще лучше написать запрос, который не упадет в случае нарушения, а потом анализировать affected rows.

_FR>Ещё лучше — или не выдавать необдуманных фраз или признавать их неправоту, чем придумывать или советовать, что лучше. Я сам могу решать, что лучше и не авторитетом давить надо ("лучше это"), а логикой.
Логика как раз говорит что лучше прекратит работу если вылетел неожиданный exception.

_FR>В данном случае быть может так, что запрос пишет неизвестный мне програмист и какие могут быть в нём ошибки не неизвестно.
И?

_FR>>>А как же быть с другими ошибками, как то нарушение ссылочной целостности?
G>>А как я его могу исправить? Если внешний ключ, который вводится не вручную, а выбирается из списка в интерфейсе, вдруг оказался невалидным, то единственное что я могу сделать — сказать "ололо кто-то поменял данные и надо перезапустить операцию".

_FR>Для этого нужно определить, что же произошло. Вы представляете себе порядок числа [различных] ошибок, которые могут возникнуть при выполнении запроса? Озвучьте пожалуйста.
Нет, именно поэтому я не буду их обрабатывать и прерву операцию.

_FR>>>>>Как нужно обработать отсутствие соединения, отсутствие процедуры, недостаток прав или какую-то проблему в самой процедуре? И почему следует закрывать приложение при этом?
G>>>>Как минимум прервать текущую операцию,
_FR>>>Можно и прервать, но это к делу не относится.
G>>Как раз относится.

_FR>Как же? Какая разница в контексте данного вопроса — "прервать", "оправить письмо" или "отформатировать жёсткий диск"
Большая разница. Это state mamgement и побочные действия.

G>>>>а в некоторых случаях и закрыть приложение (например если ошибка при старте).
_FR>>>А если не на старте?
G>>Тогда прервать операцию.

_FR>И всё? ничего не сообщая пользователю?
Конечно сообщая, я про побочные действия не говорю сейчас.

_FR>>>Вы согласны, что коментарий

А еще лучше при этом завершить приложение\текущую операцию.

зачастую не уместен?
G>>Нет, это зачастую самое лучшее решение.
G>>не забывай что большинство exception пользователь видит если в программе явно баг.
_FR>Не могу забыть, ибо не согласен с этим.
Ну приведи пример когда это не так и это не является ошибкой проектирования.


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

Ты видимо не понял что я тебе хочу сказать.

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

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

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

_FR>Да, именно это можно выделить как ключевые слова (по поему мнению). Даже если принять их на веру (мне не нравится слово "большинство") то это прямо означает, что

_FR>

А еще лучше при этом завершить приложение\текущую операцию.

_FR>не верно, потому что нет уточнения про "меньшенство", которое имеет место быть в "не забывай что большинство exception …".

Чем не нравятся споры про exception что они как-то сильно абстрактные, как доходит до кода, так сразу все эти теории по перехватыванию всего идут лесом.

G>>не забывай что большинство exception пользователь видит если в программе явно баг.

_FR>Тут от самого исключения очень много зависит. Если речь про NullReferenceException, ArgumentException или InvalidOperationException, то это однозначно баг. Если речь про MyBussinessLogicException, прилетевшую с сервера при выполнении сложной операции? На клиента прикажите добавлять информацию по всевозможным кодам ошибки? (С сиквелам указанная мной выше "проблема" того же разряда).
Ну ты же не будет все коды ошибок анализировать (как с бд), а если ты не обрабатываешь ошбику, то единственное что ты можешь сделать с точки зрения программной логики — откатиться к какому-либо безопасному состоянию (читай прервать операцию).