Лучший способ передать последнюю ошибку переадресации пользовательской ошибки?
Функции, которые используют указатели или ссылки на базовые классы, должны быть в состоянии использовать объекты производных классов, не зная это.
, Когда я сначала читал о LSP, я предположил, что это было предназначено в очень строгом смысле, по существу приравнивая его для взаимодействия через интерфейс с реализацией и безопасным с точки зрения типов броском. Который означал бы, что LSP или обеспечен или не самим языком. Например, в этом строгом смысле, ThreeDBoard, конечно, substitutable для Совета, насколько компилятор затронут.
После чтения больше на понятии, хотя я нашел, что LSP обычно интерпретируется более широко, чем это.
Короче говоря, то, что это означает для клиентского кода "знать", что объект позади указателя имеет производный тип, а не тип указателя, не ограничивается безопасностью типов. Соблюдение LSP является также тестируемым посредством зондирования объектов фактическое поведение. Таким образом, исследуя влияние состояния объекта и аргументов метода на результатах вызовов метода или типах исключений, выданных от объекта.
Возвращение к примеру снова, в теории методы Совета могут быть сделаны работать просто великолепно на ThreeDBoard. На практике однако будет очень трудно предотвратить различия в поведении, которое клиент не может обработать правильно, не создавая помехи функциональности, которую ThreeDBoard предназначается для добавления.
С этим знанием в руке, оценивая соблюдение LSP может быть большой инструмент в определении, когда состав является более соответствующим механизмом для расширения существующей функциональности, а не наследования.
5 ответов
Я думаю, что это достойный способ сделать это. Я так не поступаю, но мой код слишком длинный для публикации (и в VB.NET).
Я бы хотел изменить одну вещь, так это саму страницу с ошибкой. Вместо отображения ошибки рассмотрите возможность добавления текстового поля на страницу ошибки в качестве необязательного поля, в котором пользователь может ввести свой адрес электронной почты и нажать кнопку, чтобы отправить вам отчет об ошибке. Затем, когда вы получите отчет об ошибке, вы можете посмотреть на проблему и ответить на них. Это гораздо более удобный способ сделать это, и он неплохо сработал для сайтов, на которых я это делал.
В этом смысле, вы также можете собрать данные формы, данные сеанса и все остальное, что представляет собой ценность, и также поместить их в отчет об ошибках. Это может значительно упростить диагностику проблем.
Поскольку кеш является глобальным, это не рекомендуется, поскольку вы сказали, что можете показывать кому-то неправильную ошибку. Я также должен сказать, что вы не должны выводить сообщение об ошибке напрямую конечным пользователям по соображениям безопасности.
Обратите внимание на эту проблему:
Пользовательская страница ошибок ASP.NET, сервер GetLastError имеет значение null
Подводя итог, положите что-то вроде следующего:
Server.Transfer(String.Concat("~/Error.aspx?message=", HttpUtility.UrlEncode(ex.InnerException.Message)))
Вместо того, чтобы полагаться на ASP.NET для выполнения перенаправления с использованием настроек в разделе CustomErrors.
Мы делаем то, что может сработать, а может и не сработать. Мы ведем обширное логирование в БД. Когда мы получаем ошибку, мы регистрируем ее, и это дает идентификатор ошибки. Мы перенаправляем на общую страницу с идентификатором ошибки и получаем там подробную информацию.
конечно, это не имеет смысла, когда возникает ошибка «не удается подключиться к БД», но это случается не слишком часто;)
Я должен согласиться как с n8wrl, так и со Стивом, что лучшим подходом было бы регистрировать ошибки в базе данных, а затем возвращать пользователю только идентификатор ошибки. Им действительно не нужно видеть технические детали, и возможно, что это приведет к раскрытию конфиденциальной информации.
В нашем случае мы также передаем идентификатор пользователя (если доступен) и страницу, на которой произошла ошибка (Request. URL по-прежнему хорош, когда вы попадаете в глобальную ошибку Application_Error). Таким образом, мы можем немного легче отследить ошибку. Также обратите внимание, что вам не обязательно использовать Global.asax с тегом скрипта. Если вы создаете файл Global.asax.cs в каталоге App_Code, вы можете просто написать код на C # напрямую (хотя это может зависеть от типа проекта).
Server.ClearError();
Я думаю, эта строка должна быть помещена в Error.aspx.cs после отображения ErrorMessage.