Почему моя трассировка стека не включает страницу, с которой она была первоначально вызвана?

#c# #asp.net #exception

#c# #asp.net #исключение

Вопрос:

Насколько я понимаю asp.net исключения. Если у меня есть страница, которая вызывает некоторый код, который, в свою очередь, вызывает другой бит кода. Если последний бит кода (скажем, в другой dll) выдает исключение, и оно нигде не обрабатывается, тогда я должен заставить страницу выдать ошибку на YSOD, у которого есть трассировка стека, которая показывает в обратном хронологическом порядке, что произошло. порядок. Итак, я получу в нижней части трассировки стека первый бит кода, который был выполнен, а затем над ним следующий, проходящий весь путь до вершины, где произошла фактическая ошибка.

Имея это в виду, у меня есть приложение, которое не показывает страницу aspx в трассировке стека. Также не отображаются обычные начальные вызовы asp.net стек, как:

в System.Web.Util.CalliHelper .EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e) в System.Web.Util.CalliEventHandlerDelegateProxy .Обратный вызов (отправитель объекта, EventArgs e) в System.Web.UI.Control.Загрузка (EventArgs e) в сообщество.Поддержка.Базовая страница.OnLoad(EventArgs e) в C:ProjectsUnileverBinaryFilesSupportBasePage.cs:line 389 в System.Web.UI.Control.LoadRecursive() в System.Web.UI.Page.ProcessRequestMain(логические includeStagesBeforeAsyncPoint, логические includeStagesAfterAsyncPoint)

Я не могу понять, почему. Единственный намек, который я получаю, заключается в том, что используется отражение, и мне интересно, почему это так?

Комментарии:

1. это зависит от нескольких аспектов… например, если исключение возникает в другом потоке, вы не получите «вызывающего», поскольку оно даже не происходит в том же стеке (у каждого потока есть свой собственный стек)!

2. Трассировка стека сбрасывается, если вы повторно создаете исключение (или создаете новое исключение без сохранения существующего стека InnerException ).

3. Это не Community.Support.BasePage настоящая страница aspx? Или это может быть даже класс, который является производным от Web.UI.Page ; ваша фактическая страница aspx является производной от этого класса.

4. Вероятно, базовая страница выполняет a throw ex; в строке 389. Посмотрите на эту строку, чтобы убедиться.

Ответ №1:

Поскольку вы используете класс BasePage, отличный способ получить подробную информацию — переопределить метод onError; этот метод срабатывает для всех необработанных ошибок на странице. Затем соберите информацию о странице и добавьте ее к ошибке или добавьте ее в оператор logged.

HTH.