MSDN.WhiteKnight - Stack Overflow answers
Ответ на ""Что-то пошло не так" - как правильно информировать пользователя об ошибках"
Answer 1320838
Постоянно сталкиваюсь с приложениями, в том числе от Microsoft, разработчики которых не утруждают себя сообщать пользователям, что же на самом деле произошло, и почему приложение поломалось.
На мой взгляд, это неправильно, но тем не менее, я могу понять, почему это делается. Если сообщение об ошибке выводится пользователю, следует озаботиться тем, чтобы оно было ему понятным: переведено на тот язык, на котором он говорит, объясняло все в терминах, понятных простому пользователю и т.д. При типичном
MessageBox.Show(ex.Message)
это все обычно не соблюдается. Поэтому логичное решение - просто наплевать на это, заменив сообщение на бессмысленное, и рекомендовать опытным пользователям копаться в логах, если их очень интересует настоящее сообщение об ошибке.Другой причиной может быть бизнес-модель. Если программа бесплатная или дешевая, а основной доход разработчик получает от платной поддержки, разработчику выгоднее не предоставлять пользователю информацию для самостоятельного решения проблемы, а вывести безликий код ошибки и предложить обратиться в поддержку.
Если вы не Microsoft, рекомендую все же не следовать этому подходу, мой поход см. ниже.
catch { Console.WriteLine("Что-то пошло не так!"); }
Это почти всегда анти-паттерн. Игнорировать исключения можно, но в этом случае ничего и на экран выводить не надо, если оно ожидаемое. Когда же что-то по настоящему "пошло не так", надо хотя бы логировать.
каким способом сообщить пользователю об ошибках: интерфейс, логи, другие способы.
- В интерфейсе вывести сообщение вида
"Произошла ошибка: "+ex.GetType().ToString()+ex.Message
.- В логи записать полный вывод
ex.ToString()
(т.е, со стеком).- Через телеметрию, если она есть, также отправить на сервер полный вывод
ex.ToString()
.При таком подходе есть некий риск, что пользователь не поймет информацию, которая выведена на экран, но по мне лучше принять это, чем вставлять палки в колеса пользователю, скрывая информацию. В отличие от веб-приложений, в настольных нет риска случайной выдачи секретных данных, так как программа работает только с теми данными, которые пользователю и так доступны.
Если пользователь - программист, можно и на экран выводить стек вызовов, только не в стандартный MessageBox, а сделать свой, где стек вынесен в отдельное поле с прокруткой - как-то так:
логические типы ошибок: фатальные и т.д.
Не вижу смысла делить на фатальные и не фатальные. По настоящему фатальные, вроде Access Violation, все равно и обработать стандартными средствами не получиться. Все остальные обрабатывать нужно, даже те, которые являются следствием бага. Доводить до падения процесса и стандартного диалога "Отправьте в Microsoft..." из-за необработанного NRE строго не рекомендуется. В этом случае все несохраненные данные пользователя будут потеряны, что сильно перевешивает теоретический риск повреждения данных при продолжении работы с багом. А от отправки в Microsoft все равно толку ноль, ибо им до лампочки баги в наших поделиях.
Внимание! Раз на вопросе метка desktop, все рекомендации только для настольных приложений. Для веб приложений подход должен быть абсолютно другим.
Content is retrieved from StackExchange API.
Auto-generated by ruso-archive tools.