Бросая исключение с внутренней SecurityException отображает только внутреннее исключение в ASP.NET MVC

Question

Если я добавлю следующую строку в метод действия ASP.NET MVC

throw new Exception("outer", new SecurityException("inner"));

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

SecurityException

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

Сведения об исключении: System.Security.SecurityException: inner

Ошибка источника:

Во время выполнения текущего веб-запроса было сгенерировано необработанное исключение.Информацию о происхождении и местонахождении исключения можно определить с помощью приведенной ниже трассировки стека исключений.

Трассировка стека:

[SecurityException: inner]

Является ли этоожидаемое поведение?

Кажется, не имеет значения, к какому типу относится внешнее исключение.Даже если это другое исключение SecurityException, сообщение никогда не отображается.Сообщение об ошибке SecurityException по умолчанию настолько расплывчато, что я хочу его перехватить и добавить более конкретную информацию.Это прекрасно работает, если я не включаю исходное исключение SecurityException в качестве innerException, но в идеале я хотел бы сделать это.

Answer 1

Это поведение происходит в «ядре» ASP.NET, а не в ASP.NET MVC.К сожалению, классы средства форматирования ошибок являются внутренними, и типы потребления не предоставляют никаких точек расширения, которые позволили бы настроить поведение без замены механизма сообщения об ошибках.Обходной путь должен заменить стандартную страницу «желтого экрана смерти» пользовательской страницей / представлением об ошибке, в котором каждый предоставляет информацию, которую предпочитает.В вашем случае это просто означает, что у вас будет альтернативная версия для отладки вместо использования по умолчанию, предоставляемого ASP.NET.

Answer 2

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

throw new SecurityException("user should not be allowed to access this method...");

в такой ситуации, чего вам не хватает в журнале или на странице?

если вы используете глобальный обработчик исключений приложения и входите оттуда с помощью Log4Net или NLog, вы сможете получить доступ ко всей цепочке исключений от внешнего к внутреннему и т. Д. В зависимости от того, как вы настраиваете и используетерамки ведения журнала.Желтая страница IIS / ASP.NET может быть неполной, но в любом случае должна отображать трассировку стека.

, если вы хотите выбросить собственное исключение из блока catch, вы оборачиваете фактическое исключение, полученное из catch в этомпуть:

throw new SecurityException("user should not be allowed...", exc);

Редактировать : попробовал то, что вы предложили, и Log4Net зарегистрировал следующее в текстовом файле:

System.Security.SecurityException: более явное исключение ---> System.Security.SecurityException: исходное исключение в EDICheckerApp.Program.boom () в C: \ DEV_RPP \ Program.cs: строка 45
--- Конец внутренней трассировки стека исключений --- в EDICheckerApp.Program.boom () в C: \ DEV_RPP \ Program.cs: строка 49
в EDICheckerApp.Program.Main (String [] args) в C:\ DEV_RPP \ Program.cs: строка 27