Хорошо, я вас понял. Но предлагаете ли вы таким образом использовать один класс для одного случая? (В идеале).
Простите мне мою дотошность, я хочу понять принципиальное отличие от нумерации. Я рассматривал ваш вариант, но пришёл к выводу, что мне проще нумеровать исключения, чем строить иерархию как раз потому, что не хотел писать 100-200 и более классов исключений и столько же обработчиков. При том, что у меня сквозная нумерация и по исключениям и по предупреждающим сообщениям. Т.е. у меня уникальное число независимо от того, кто его сгенерировал - исключение или просто предупреждение в интерфейсе или вывод в лог. Соответственно формат всех чисел в исходном коде у меня начинается с символа подчёркивания и вид числа _1234 никогда не встречается в коде. Поэтому я всегда однозначно могу найти место в программе, которое генерирует сообщение вообще без контекста - исключение ли это, предупреждение или запись в логи.
Мой ответ такой: для каждой неожидаемой ситуации в системе использовать исключение (нормально если их сотня и больше). Это исключение не должно показываться пользователю.
Но вот я и спрашиваю - а писать новый класс для каждого из 100-200 исключений нужно ли?
Но разбор таких ошибок - это уже немного другая область. Но опять же, в инете можно поискать что означает ошибка синего экрана с номером x80005142563 и т.д. Т.е. поиск можно начать с конкретного числа. Сам stacktrace уже вторичен. Но опять же - всё сходится на определённом числе независимо от типа исключения. Это же хорошо?
Или больше работайте. ))) (сарказм) Эта ситуация как раз не исключение, а штатная и комментария будет вполне достаточно, чтобы пользователь понимал что случилось, хотя я бы не был так уверен, что всё корректно, ведь недостаток средств может быть порождён какими-то внутренними проблемами банка. (Но это нюансы).
Мне не очень понятно, почему вы считаете, что исключение, которое нельзя обработать автоматически, не должно показываться пользователю? Он же всё равно не может выполнить какую-то операцию? Что ему тогда показывать? (или я чего-то не понимаю?)
Для отображения пользователю я вообще не стал бы их использовать.
Подождите, я переосмыслил ваш ответ, но речь шла не об неиспользовании, а как раз о том, что на каждое исключение делать уникальный класс исключений, а то что вы советуете не использовать для отображения пользователю не означает, что их не надо делать? Поэтому я и сказал, что это накладно, т.к. на каждое уникальное исключение, которых могут быть тысячи, вы предлагали делать уникальный класс исключения? Так ли это или не так?
Для отображения пользователю я вообще не стал бы их использовать.
Теперь я вас понял. Но, как тогда общаться с пользователем, у которого возникло исключение (за исключением ситуации, когда исключения можно обработать автоматически)
Возможно вы пишете код для микроконтроллеров
Нет, я выше написал, что речь о проектировании в строительстве. Там на пожеланиях пользователей чёрт ногу сломит. "Шаг вправо, шаг влево - побег, прыжок на месте - провокация." )))
У нас ответственность на уровне модуля. Ставится задача отдельному сотруднику, он пишет небольшой модуль. Из него делается nuget-пакет и он попадает в проект.
Общего владения кодом пока нет и не думаю, что он появится. Совершенно разные специфики по работам. Компания небольшая.
Ок, но пусть даже и большая компания, но взять тот же синий экран "смерти" Windows. У него есть число и, может быть, файл с трассировкой стека. Но ведь число? О нём речь и идёт, о числе.
Моё личное мнение - не стоит плодить разные контексты для чисел, которые показываются пользователю. Можно придумать ещё какой-нибудь контекст, например, pidId и другие разные Id. Но пользователю, который столкнулся с исключением в конкретный момент прохождения алгоритма своего решения от этого не легче.
Я не понимаю, почему по traceId можно решить свою ошибку, а по коду ошибки нет? (В случае проблем при взаимодействии с вашей системой пользователь видит два числа Код Ошибки и TraceId или что-то одно?)
Интересно, а можно ли создать такой аккаунт после его удаления? У меня был случай, что я хотел сделать аккаунт на Gmail, но во время регистрации что-то пошло не так и я перезапустил мастера создания аккаунта. Но вот тут я и обломился, т.к. если создание аккаунта было прервано, то повторить процесс создания уже нельзя. Так обидно. Уже много лет прошло…
В принципе, если traceid детерминантный (т.е. на одну и ту же ошибку в одном и том же месте программы выдаётся один и тот же код), то разницы нет. А вот если разный, то это плохо. Но я работаю на C# и у меня нет MDC. Кстати, при изменении исходного кода изменяется traceid?
Пример предупреждения пользователю (сорри если некоторые тексты сообщений не очень понятны - уж что попросили конструкторы, то я и написал. На мои вопросы они отвечают - "мы знаем что это значит, оставьте так". Ок):
Пример в логах:
Пример исключения для логов (в данном случае исключение 172 чуть позже бросается):
Пользователю в этом случае наверно надо было бы отобразить - введите другой телефон, а не код ошибки 2051 - смотрите по доке что это значит
Так я же не требую выводить только код ошибки. Добавьте после кода ошибки сопроводительный текст и информация будет предоставлена в том же виде, что и раньше. 3-5 символов на числовой код ошибки не сильно что-то испортят в сообщение, но зато у пользователя и разработчика/оператора программы будет предметный разговор. Например, мне звонит сотрудник и говорит, что у меня на экране сообщение: "...", и сообщает оператору первое же число - код ошибки: "172" А у оператора перед глазами список действий, которые он может предложить пользователю по этому номеру. Согласитель, общение же более конкретное, чем спрашивать, как он к этому сообщению попал? Примерно всегда можно установить даже ФИО разработчика, который этот генератор/обработчик ошибки написал. Известное выражение: "У каждой ошибки есть имя и фамилия". /s
Если требуется какая-то автоматическая обработка исключений, то номер ошибки можно добавить не только в сообщение, но и в конструктор, а потом его как-то использовать.
Да, и напомню, что мне всё ещё интересно как вы предлоагаете выйти из ситуации с количеством классов исключений для большого количества ошибок? Писать же отдельный класс на каждую ошибку очень накладно.
Одно исключение должно кидаться как можно в меньшем количестве мест и должно быть как можно более уникальным - тогда не будет проблем с поиском по коду
Честно говоря я не согласен с этим потому что в моём примере в проекте последний номер ошибки на сегодняшний день 2051. Как в этом случае вы предлагаете мне поступить - создать примерно такое количество классов исключений? (Я не думаю, что вы хотели, чтобы я сделал именно так, но исходя из вашего предложения я не могу представить себе чего-то другого).
P.S.
Меня тема исключения очень волнует, т.к. пользователи обожают параметризацию, поэтому за вводом параметров нужно следить очень точно, а ошибки, похожие друг на друга, встречаются как раз в большом количестве случаев, потому что выход из контекста бывает только на втором или третьем слое бизнес-логики. Получается такой своеобразный подъём с глубины от случая, когда просто не хватает какого-то параметра, до случая, что операцию сделать нельзя, потому что три-четыре-пять параметров находятся в противоречии друг с другом. Вроде как это не исключение, но дальше проблемы копятся как снежный ком - с одной стороны очень хочется бросить исключение, но с другой было бы неплохо проверить работу остальных параметров, которые не связаны с параметрами, которые породили текущее исключение. Т.е. хорошо бы пользователю давать подробный отчёт о качестве всех его данных, а не только о тех, на которых получено первое исключение, а до следующего просто "руки"/"код" не дошёл.
P.P.S.
Тему вы подняли очень важную - исключения - это только только верширна айсберга при обработке ошибок. )))
Как можно реже используйте комментарии. Чем больше комментариев вы пишете, тем больше программисты не обращают на это внимания.
Прям выглядит как шутка. У меня раз в полгода-год просят добавить какие-то параметры в форме из 150 значений (проектирование в строительстве). И везде в коде стоят комментарии что и куда прописать. Читаю комментарии, делаю по алгоритму, может даже что-то добавляю в комментарии и забываю на следующие полгода-год. )))
Во всей этой чехарде с исключениями, особенно когда их много больше всего меня напрягали формулировки, потому что даже при логировании достаточно трудно провести поверхностный анализ того, что происходит, т.к. формулировки в логах могут совпадать. Потом я попробовал применить уникальную нумерацию сообщений в исключениях. И это дало приличные результаты: пользователь звонит и говорит номер ошибки, а что написано в сообщении уже почти не важно. Теперь легко сопоставить ошибку с кодом, а в логах найти историю этой ошибки по другим номерам от других сообщений. Своеобразный stackTrace по бизнеслогике. И пользователю не надо сильно распинаться и разработчику и саппорту проще понять, что происходит и как начать разговор. Например, вместо долгих объяснение что делалось, что ожидалось и т.д. просто говоришь номер ошибки, а т.к. они все уникальны, то выспрашивание контекста можно делать на самой последней стадии общения. И, кстати, нумерация исключений вполне может скрывать реализацию исключений. От пользователя иногда достаточно получить номер ошибки, чтобы понять контекст. Кстати, введение нумерации добавляет уверенности пользователю, что это не он дурак, а в системе предусмотрен обработчик и пользователю нужно запомнить, что сделано не так, чтобы избежать такой ошибки в будущем.
Честно говоря, примеры исключений, вписанных в статье, лично мне кажутся не очень хорошей практикой. Нет четкой связи с кодом, где возникло исключение. Там, где хоть какое-то описание контекста попадает в исключение ещё можно связать с местом в коде, а там где исключение просто бросается, например, что «нет такой валютной пары», так и потом даже с логами не понять, что произошло: в логах нет намёка, что исключение брошено, а брошенное исключение никак не связано с записью в журнале логов. Может добавить сообщение в конструктор исключения при вызове исключения + нумерация? (Это как предложение) Например, «5843. Нет такой валютной пары» и «6432. Нет такой валютной пары» могут быть в разных местах кода и по номеру проще понять где они брошены.
Ну так можно и дальше пойти. Может тот, кто писал и не знал, зачем эта функция, тогда тут вообще нарисовывается преступная группа по незаконному обогащению. Я сам не юрист вообще, но иногда на глаза попадались статьи и книги, где студенты юридических факультетов «разруливали» такие ситуации.
У меня в школе преподаватель любил шутку: «закладываешь программу в компьютер, а уж она сама покупателя обсчитывает». Видимо некоторые решили воплотить её в жизнь.
Я как-то тоже однажды столкнулся с подобной ситуацией и не стал исправлять, потому что тут речь шла о программе за которую ещё не заплатили, но я предупредил человека, что закладка есть. (У разработчика было ещё много времени на её удаление, т.к. итераций ещё было много). Поэтому как способ гарантии выплаты за работу вполне себе вариант. Но лучше, конечно, поддерживать хорошие деловые отношения.
Все вопросы после того, как только вы напишите - «извините, был не прав, плохо владел информацией». Вы написали, что финский ЦОД был отжат, но как оказалось - это неправда, значит вы солгали. Жду извинений, которые обычно приносят приличные люди, отвечающие за свои слова.
Хорошо, я вас понял. Но предлагаете ли вы таким образом использовать один класс для одного случая? (В идеале).
Простите мне мою дотошность, я хочу понять принципиальное отличие от нумерации. Я рассматривал ваш вариант, но пришёл к выводу, что мне проще нумеровать исключения, чем строить иерархию как раз потому, что не хотел писать 100-200 и более классов исключений и столько же обработчиков. При том, что у меня сквозная нумерация и по исключениям и по предупреждающим сообщениям. Т.е. у меня уникальное число независимо от того, кто его сгенерировал - исключение или просто предупреждение в интерфейсе или вывод в лог. Соответственно формат всех чисел в исходном коде у меня начинается с символа подчёркивания и вид числа _1234 никогда не встречается в коде. Поэтому я всегда однозначно могу найти место в программе, которое генерирует сообщение вообще без контекста - исключение ли это, предупреждение или запись в логи.
Но вот я и спрашиваю - а писать новый класс для каждого из 100-200 исключений нужно ли?
Но разбор таких ошибок - это уже немного другая область. Но опять же, в инете можно поискать что означает ошибка синего экрана с номером x80005142563 и т.д. Т.е. поиск можно начать с конкретного числа. Сам stacktrace уже вторичен. Но опять же - всё сходится на определённом числе независимо от типа исключения. Это же хорошо?
Или больше работайте. ))) (сарказм) Эта ситуация как раз не исключение, а штатная и комментария будет вполне достаточно, чтобы пользователь понимал что случилось, хотя я бы не был так уверен, что всё корректно, ведь недостаток средств может быть порождён какими-то внутренними проблемами банка. (Но это нюансы).
Мне не очень понятно, почему вы считаете, что исключение, которое нельзя обработать автоматически, не должно показываться пользователю? Он же всё равно не может выполнить какую-то операцию? Что ему тогда показывать? (или я чего-то не понимаю?)
Подождите, я переосмыслил ваш ответ, но речь шла не об неиспользовании, а как раз о том, что на каждое исключение делать уникальный класс исключений, а то что вы советуете не использовать для отображения пользователю не означает, что их не надо делать? Поэтому я и сказал, что это накладно, т.к. на каждое уникальное исключение, которых могут быть тысячи, вы предлагали делать уникальный класс исключения? Так ли это или не так?
Теперь я вас понял. Но, как тогда общаться с пользователем, у которого возникло исключение (за исключением ситуации, когда исключения можно обработать автоматически)
Нет, я выше написал, что речь о проектировании в строительстве. Там на пожеланиях пользователей чёрт ногу сломит. "Шаг вправо, шаг влево - побег, прыжок на месте - провокация." )))
У нас ответственность на уровне модуля. Ставится задача отдельному сотруднику, он пишет небольшой модуль. Из него делается nuget-пакет и он попадает в проект.
Общего владения кодом пока нет и не думаю, что он появится. Совершенно разные специфики по работам. Компания небольшая.
Ок, но пусть даже и большая компания, но взять тот же синий экран "смерти" Windows. У него есть число и, может быть, файл с трассировкой стека. Но ведь число? О нём речь и идёт, о числе.
Моё личное мнение - не стоит плодить разные контексты для чисел, которые показываются пользователю. Можно придумать ещё какой-нибудь контекст, например, pidId и другие разные Id. Но пользователю, который столкнулся с исключением в конкретный момент прохождения алгоритма своего решения от этого не легче.
Я не понимаю, почему по traceId можно решить свою ошибку, а по коду ошибки нет? (В случае проблем при взаимодействии с вашей системой пользователь видит два числа Код Ошибки и TraceId или что-то одно?)
P.S.
Спасибо за подсказку с библиотекой, посмотрю.
"На чужих ошибках всему не научишся."
Можно поинтересоваться, а что за канал?
Интересно, а можно ли создать такой аккаунт после его удаления? У меня был случай, что я хотел сделать аккаунт на Gmail, но во время регистрации что-то пошло не так и я перезапустил мастера создания аккаунта. Но вот тут я и обломился, т.к. если создание аккаунта было прервано, то повторить процесс создания уже нельзя. Так обидно. Уже много лет прошло…
В принципе, если traceid детерминантный (т.е. на одну и ту же ошибку в одном и том же месте программы выдаётся один и тот же код), то разницы нет. А вот если разный, то это плохо. Но я работаю на C# и у меня нет MDC. Кстати, при изменении исходного кода изменяется traceid?
Но вы ещё так и не ответили на мой вопрос. )
Да, конечно. Можно прямо в коде:
Пример предупреждения пользователю (сорри если некоторые тексты сообщений не очень понятны - уж что попросили конструкторы, то я и написал. На мои вопросы они отвечают - "мы знаем что это значит, оставьте так". Ок):
Пример в логах:
Пример исключения для логов (в данном случае исключение 172 чуть позже бросается):
Так я же не требую выводить только код ошибки. Добавьте после кода ошибки сопроводительный текст и информация будет предоставлена в том же виде, что и раньше. 3-5 символов на числовой код ошибки не сильно что-то испортят в сообщение, но зато у пользователя и разработчика/оператора программы будет предметный разговор. Например, мне звонит сотрудник и говорит, что у меня на экране сообщение: "...", и сообщает оператору первое же число - код ошибки: "172" А у оператора перед глазами список действий, которые он может предложить пользователю по этому номеру. Согласитель, общение же более конкретное, чем спрашивать, как он к этому сообщению попал? Примерно всегда можно установить даже ФИО разработчика, который этот генератор/обработчик ошибки написал. Известное выражение: "У каждой ошибки есть имя и фамилия". /s
Если требуется какая-то автоматическая обработка исключений, то номер ошибки можно добавить не только в сообщение, но и в конструктор, а потом его как-то использовать.
Да, и напомню, что мне всё ещё интересно как вы предлоагаете выйти из ситуации с количеством классов исключений для большого количества ошибок? Писать же отдельный класс на каждую ошибку очень накладно.
Честно говоря я не согласен с этим потому что в моём примере в проекте последний номер ошибки на сегодняшний день 2051. Как в этом случае вы предлагаете мне поступить - создать примерно такое количество классов исключений? (Я не думаю, что вы хотели, чтобы я сделал именно так, но исходя из вашего предложения я не могу представить себе чего-то другого).
P.S.
Меня тема исключения очень волнует, т.к. пользователи обожают параметризацию, поэтому за вводом параметров нужно следить очень точно, а ошибки, похожие друг на друга, встречаются как раз в большом количестве случаев, потому что выход из контекста бывает только на втором или третьем слое бизнес-логики. Получается такой своеобразный подъём с глубины от случая, когда просто не хватает какого-то параметра, до случая, что операцию сделать нельзя, потому что три-четыре-пять параметров находятся в противоречии друг с другом. Вроде как это не исключение, но дальше проблемы копятся как снежный ком - с одной стороны очень хочется бросить исключение, но с другой было бы неплохо проверить работу остальных параметров, которые не связаны с параметрами, которые породили текущее исключение. Т.е. хорошо бы пользователю давать подробный отчёт о качестве всех его данных, а не только о тех, на которых получено первое исключение, а до следующего просто "руки"/"код" не дошёл.
P.P.S.
Тему вы подняли очень важную - исключения - это только только верширна айсберга при обработке ошибок. )))
По моему весь спускаемый модуль руками собирали, а вопросы только к надписи? /s
Прям выглядит как шутка. У меня раз в полгода-год просят добавить какие-то параметры в форме из 150 значений (проектирование в строительстве). И везде в коде стоят комментарии что и куда прописать. Читаю комментарии, делаю по алгоритму, может даже что-то добавляю в комментарии и забываю на следующие полгода-год. )))
Во всей этой чехарде с исключениями, особенно когда их много больше всего меня напрягали формулировки, потому что даже при логировании достаточно трудно провести поверхностный анализ того, что происходит, т.к. формулировки в логах могут совпадать. Потом я попробовал применить уникальную нумерацию сообщений в исключениях. И это дало приличные результаты: пользователь звонит и говорит номер ошибки, а что написано в сообщении уже почти не важно. Теперь легко сопоставить ошибку с кодом, а в логах найти историю этой ошибки по другим номерам от других сообщений. Своеобразный stackTrace по бизнеслогике. И пользователю не надо сильно распинаться и разработчику и саппорту проще понять, что происходит и как начать разговор. Например, вместо долгих объяснение что делалось, что ожидалось и т.д. просто говоришь номер ошибки, а т.к. они все уникальны, то выспрашивание контекста можно делать на самой последней стадии общения. И, кстати, нумерация исключений вполне может скрывать реализацию исключений. От пользователя иногда достаточно получить номер ошибки, чтобы понять контекст. Кстати, введение нумерации добавляет уверенности пользователю, что это не он дурак, а в системе предусмотрен обработчик и пользователю нужно запомнить, что сделано не так, чтобы избежать такой ошибки в будущем.
Честно говоря, примеры исключений, вписанных в статье, лично мне кажутся не очень хорошей практикой. Нет четкой связи с кодом, где возникло исключение. Там, где хоть какое-то описание контекста попадает в исключение ещё можно связать с местом в коде, а там где исключение просто бросается, например, что «нет такой валютной пары», так и потом даже с логами не понять, что произошло: в логах нет намёка, что исключение брошено, а брошенное исключение никак не связано с записью в журнале логов. Может добавить сообщение в конструктор исключения при вызове исключения + нумерация? (Это как предложение) Например, «5843. Нет такой валютной пары» и «6432. Нет такой валютной пары» могут быть в разных местах кода и по номеру проще понять где они брошены.
Ну так можно и дальше пойти. Может тот, кто писал и не знал, зачем эта функция, тогда тут вообще нарисовывается преступная группа по незаконному обогащению. Я сам не юрист вообще, но иногда на глаза попадались статьи и книги, где студенты юридических факультетов «разруливали» такие ситуации.
У меня в школе преподаватель любил шутку: «закладываешь программу в компьютер, а уж она сама покупателя обсчитывает». Видимо некоторые решили воплотить её в жизнь.
Я как-то тоже однажды столкнулся с подобной ситуацией и не стал исправлять, потому что тут речь шла о программе за которую ещё не заплатили, но я предупредил человека, что закладка есть. (У разработчика было ещё много времени на её удаление, т.к. итераций ещё было много). Поэтому как способ гарантии выплаты за работу вполне себе вариант. Но лучше, конечно, поддерживать хорошие деловые отношения.
)))
Так это к разработке уже не имеет отношения. Это «бизнес». Ведь зарабатывать «пыталась» уже не компания производитель оборудования.
Все вопросы после того, как только вы напишите - «извините, был не прав, плохо владел информацией». Вы написали, что финский ЦОД был отжат, но как оказалось - это неправда, значит вы солгали. Жду извинений, которые обычно приносят приличные люди, отвечающие за свои слова.
А что такое РФ в вашем понимании? И почему компании должны вашему РФ, а ваша РФ им ничего не должна?