Разрыв Visual Studio 2015 на необработанных исключениях не работает


114

В Visual Studio раньше был специальный флажок для «Прервать необработанное исключение». В 2015 году это было удалено (или перемещено куда-то, я не могу его найти). Так что теперь мои преобразованные проекты больше не ломаются, если я не могу предоставить обработчик исключений на уровне пользователя. Я не хочу останавливаться на всех «брошенных исключениях», потому что я обрабатываю определенные. Именно там, где я не могу указать конкретного обработчика.

Прямо сейчас мой код просто выходит из текущей процедуры и продолжает выполнение в следующем месте стека вызовов, НЕ ХОРОШО.

Кто-нибудь знает, как вернуть это в Visual Studio 2015? Я только вчера обновился до версии для сообщества.


Visual Studio 2015 сохранит текущий макет из предыдущей версии, если на вкладке Toolили не Windowбудут все нужные места. В вашем случае вы ищете настройки исключений .
Грег

4
@greg, дело не в том, что я не знаю, где найти панель. Меня беспокоит то, что поведение, которое я ищу, отсутствует на этой панели.
Тед Лоури

такая же проблема здесь. В нашем случае мы ожидаем прерывания исключения, когда в autofac зарегистрированы не все типы. Используя то же решение с vs2013, он работает, в vs2015 мы ничего не получаем. это также проблема с другими сторонними регистрациями и исключениями (например, nservicebus). Интересно, относится ли это только к проекту, созданному в vs2013 и запущенному в vs2015,
Choco Smith

3
Это новое окно инструментов действительно отстой.
cedd

Согласно классификации исключений MS, если у вас есть необработанное исключение, оно всегда нарушает работу отладчика. Возможно, вам нужно установить флажок «Прерывание, когда исключения пересекают домен приложения ...» в списке «Параметры -> Отладка -> Общие».
tsul 04

Ответы:


118

Есть новое окно под названием «Настройки исключения», которое по умолчанию появляется в нижней правой панели, когда вы начинаете отладку. В нем есть все возможные варианты.

Вы можете поднять это с помощью CTRL+ ALT+E

Это позволяет вам выбрать, какие исключения вызывают сбой в отладчике.

Ключевым моментом, однако, является то, что вы также можете установить, всегда ли эти исключения прерываются или прерываются только тогда, когда это необработанное исключение, но установка этого не очень интуитивно понятна.

Сначала вам нужно будет установить флажок «Включить только мой код» в меню «Инструменты»> «Параметры»> «Отладка».

Затем это позволяет вам щелкнуть правой кнопкой мыши заголовок столбца («Прерывание при появлении») в новом окне «Параметры исключений» и добавить столбец «Дополнительные действия», который затем позволяет вам установить для каждого исключения значение «Продолжать, когда не обрабатывается в пользовательском коде».

Поэтому просто щелкните правой кнопкой мыши исключение или всю группу и отключите флаг «Продолжить, когда не обрабатывается в пользовательском коде». К сожалению, столбец «Дополнительные действия» окажется пустым, что совпадает с «Прерыванием при необработанном в пользовательском коде».

введите описание изображения здесь

Подробнее об этом здесь:

http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx


7
На самом деле в этом окне есть только варианты «разбить с брошенным». Я не этого хочу. Я хочу "сломаться в нерабочем состоянии".
Тед Лоури

17
и в этом проблема. НЕ ломается. как я сказал выше, он выходит из текущего вызова процедуры и просто начинает выполнение следующей строки кода в вызывающей процедуре.
Тед Лоури

2
и у меня включен "Только мой код".
Тед Лоури

19
@TomStudee У меня такая же проблема. Что я хочу, так это «Разбить при необработанном», но получаю «Разрыв при броске». Возникает вопрос: как получить "Разрыв без обработки"?
ogggre

1
@TomStudee Я просто добавил некоторые столь необходимые пояснения, так как вам не хватало ключевой настройки, которая позволяет вам устанавливать исключения, которые будут прерываться только в необработанном виде.
Джерад Роуз,

36

У меня была такая же проблема, и мне удалось решить ее, выполнив это -

  1. Нажмите Ctrl+ Alt+, eчтобы открыть окно настроек исключений .
  2. Отметьте « Исключения среды CLR» . введите описание изображения здесь

Это оно!

Этот пост меня вдохновил, так как я использую 64-разрядную версию Windows .


7
Это приведет к сбою всех исключений, даже тех, которые обрабатываются пользовательским кодом.
carlin.scott

1
@ carlin.scott, я считаю, что вы можете вручную снять отметку с исключений, которые обрабатываются из списка.
Justin XL

6
@JustinXL Проблема в том, что это список по типу исключения, а не по тому, обработано оно или нет. Например, бывают случаи, когда System.ArgumentExceptionобрабатываются, а иногда - нет. Меня волнует только поломка, когда с ней не обращаются.
Jerad Rose

1
@JeradRose Отладчик всегда прерывается , когда исключение не обрабатывается. Итак, как я уже сказал, если вы не хотите, чтобы перерыв в обработанных исключениях, просто снимите отметку с этих типов исключений в списке « Прерывание при выбросе» .
Justin XL

Даже при проверке все не ломается по исключению: / просто выхожу
Дуглас Гаскелл

10

Для гуглера, который хочет прервать работу только тогда, когда исключение касается их кода, в Visual Studio 2015 есть опция: Параметры-> Отладка-> Общие-> Только мой код. После проверки он позволяет не прерываться, когда исключение обрабатывается (генерируется и перехватывается) вне вашего кода.


Это спасло меня от другой ситуации, когда VS2015 по какой-то причине отказывался вводить какой-то код. Код «мой», но что-то сработало флаг «Только мой код». Я предполагаю, что где-то есть ошибка при запуске 2 экземпляров VS и автономного веб-сервера и, возможно, еще нескольких.
LosManos

9

Microsoft тонко изменила логику в новом окне исключений.

См. Http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx

Ключевой частью является:

Важные заметки

  • Это новое окно содержит все те же функции, что и старое модальное диалоговое окно. Никакие возможности отладчика не изменились, только способ доступа к ним
  • Отладчик всегда ломается, когда исключение не обрабатывается.
  • Параметр, который нужно изменить, если отладчик прерывает работу из-за необработанных пользователем исключений, перемещен в контекстное меню.
  • Расположение меню перемещено в Debug -> Windows -> Exception Settings.

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

Чтобы вернуть поведение, при котором VS прерывается при необработанных исключениях, мне пришлось отметить все типы исключений, которые я хотел нарушить, а затем, во-вторых, убедиться, что «Дополнительные параметры» (вам может потребоваться сделать этот столбец видимым *) для «Продолжить когда не обрабатывается в коде пользователя " НЕ был установлен. Логика VS2015 , похоже, не считает, что мой глобальный обработчик необработанных исключений «обрабатывается в пользовательском коде», поэтому он действительно нарушает их; однако он не ломается при обнаружении исключений. Это заставляет его работать так же, как VS2013.

* Как включить столбец «Дополнительные действия» * Как включить столбец «Дополнительные действия»


2
Это не работает точно так же, как VS2013, потому что это нарушает обрабатываемые пользователем исключения с предложенными вами настройками, чего не было в прошлом.
carlin.scott

Как сделать видимым столбец «Дополнительные параметры»?
UuDdLrLrSs

@DaveInCaz Щелкните правой кнопкой мыши заголовок столбца> «Показать столбцы»> «Дополнительные действия»
oatsoda

7

Если я правильно читаю здесь между строк, проблема в том, что ваше исключение эффективно «исчезает», хотя поведение отладчика по умолчанию должно нарушаться при необработанных исключениях.

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

Например, взгляните на этот код:

class Program
{
    static void Main(string[] args)
    {
        Test();
        Console.ReadLine();
    }

    private async static Task Test()
    {
        await Task.Delay(100);
        throw new Exception("Exception!");
    }
}

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

Обратите внимание, что в этом случае настоящая проблема заключается в том, что Taskвозвращаемый объект Test()никогда не проверяется. Если в вашем коде есть аналогичные типы логики «запустил и забыл», вы не увидите исключения в момент их создания (даже если они «не обрабатываются» внутри метода); исключение появляется только тогда, когда вы наблюдаете за Задачей, ожидая ее, проверяя ее Результат или явно просматривая ее Исключение.

Это всего лишь предположение, но я думаю, что вы, вероятно, наблюдаете что-то подобное.


Хотя это может не быть связано с проблемой оператора, он поднимает очень хороший вопрос об исключениях, возникающих в асинхронных подпрограммах.
Фил Купер

Есть ли способ остановить отладчик, даже если исключение хранится таким образом?
Лукас

@Lucas, Не то, чтобы я в курсе, хотя вы можете приблизиться с некоторыми изменениями кода. Если в теле вашего метода «запустил и забыл» есть блок try-catch, вы можете добавить явный Debugger.Break()вызов. В качестве альтернативы вы можете добавить явное значение Debugger.Break()в TaskScheduler.UnobservedTaskExceptionобработчике, хотя недостатком здесь является то, что это может сработать намного позже, чем исходное исключение, как это происходит в потоке финализатора, когда задача очищается. В общем, вы должны стремиться всегда наблюдать за результатами задачи или, по крайней мере, иметь блок try-catch для регистрации в момент сбоя.
Дэн Брайант

3

По моему опыту, настройки исключения в 2015 году полностью выходят из строя, если вы что-то меняете.

Ожидайте, что если вы доедете до родительской группы «CLR», вы не должны получить никаких нарушений execpt для unhandled. Вы всегда сломаетесь, если исключение останется необработанным. Но если у вас отключена группа CLR, код внутри try ... catch просто не должен вызывать прерывание. Это не относится к делу.

Решение: в новой панели инструментов настроек исключений щелкните правой кнопкой мыши и выберите «восстановить по умолчанию». Таадаааа ... Опять нормально ведет себя. Теперь не лажайте с этим.


1

Попробуйте следовать инструкциям:

  1. В окне «Параметры исключения» откройте контекстное меню, щелкнув его правой кнопкой мыши и выбрав «Показать столбцы». (Если вы отключили Just My Code, вы не увидите эту команду.)
  2. Вы должны увидеть второй столбец с именем Дополнительные действия. В этом столбце отображается «Продолжить», если пользовательский код не обрабатывает определенные исключения, что означает, что отладчик не прерывает работу, если это исключение не обрабатывается в пользовательском коде, а обрабатывается во внешнем коде.
  3. Вы можете изменить этот параметр либо для конкретного исключения (выберите исключение, щелкните правой кнопкой мыши и выберите / отмените выбор «Продолжить, когда не обрабатывается в коде пользователя») или для всей категории исключений (например, для всех исключений среды CLR).

https://msdn.microsoft.com/en-us/library/x85tt0dd.aspx


Абсолютно согласен. Ужасно не показывать этот столбец по умолчанию. Потратил много времени, чтобы найти его. К тому же, что означает « пользовательское необработанное исключение », довольно неясно. У меня был обработчик отмены задачи (что-то вроде try { task.Wait(); } catch { ... }), и OperationCanceledException в задаче каким-то образом считалась необработанной в пользовательском коде.
tsul 04

1

Все это немного сбивает с толку и, на мой взгляд, не так хорошо, как старый диалог исключений, но все равно.

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

Если исключение не отмечено флажком или отсутствует в списке, отладчик будет отключен только в том случае, если этот тип исключения не обработан пользователем.

Например, на приведенном ниже снимке экрана отладчик прерывается всякий раз, когда System.AccessViolationExceptionвызывается a , но для всех остальных исключений он прерывается только в том случае, если исключение не было обработано пользователем.

Окно инструмента исключения Visual Studio 2015


1

Когда я обновился до VS2015, у меня также были проблемы, когда исключения использовались для «поломки» приложения, но теперь игнорируются и пропускаются. Бывают случаи, когда мы хотим, чтобы наш код намеренно генерировал исключения в тех местах, где мы хотим, чтобы код остановился, а не продолжался. Мы всегда используем фразу, Throw New Exception("Message")чтобы заставить наш код намеренно сломаться:

    If SomethingReallyBad = True Then
        Throw New Exception("Something Really Bad happened and we cannot continue.")
    End If

В VS2015, когда мы говорим, возникает классическое «System.Exception» Throw New Exception. Поэтому нам нужно было поставить галочку "System.Exception" в новых настройках исключения:

Установите флажок System.Exception.

После проверки наш код работал так, как ожидалось.


1

Решение состоит в том, что это семантически противоположно тому, что, по вашему мнению, вы устанавливаете. Вам необходимо убедиться, что параметр Продолжать, когда не обрабатывается в пользовательском коде , не включен, т.е. не отмечен, как показано в столбце Дополнительные действия на вкладке настроек исключения - см. Ниже:

вы фактически говорите, что не продолжайте (т.е. не прерывайте), когда не обрабатываются в коде

Окно настроек исключения (Control + Alt + E)

Сделать это:

  1. Щелкните правой кнопкой мыши исключение или набор исключений, которые вас интересуют (например, обычно верхняя строка «Исключения среды CLR» в дереве)
  2. В коде пользователя выберите вариант « Продолжить, когда не обрабатывается» (см. Ниже)
  3. Убедитесь, что исключения не отмечены (см. Ниже)
  4. продолжить отладку

введите описание изображения здесь

Это сделало это для меня - снова счастлив.

Это было в VS 2015


0

В Visual Studio определенно есть ошибка, которая может привести к зависанию, требующему перезапуска. Даже VS2015.

У меня была однопоточная ситуация, когда a NullReferenceExceptionбыл пойман «внешним» обработчиком (все еще в моем коде), хотя я просил, чтобы он сломался, когда он был вызван.

Я понимаю, что это «обработанное» исключение, а вы говорите «необработанное» - однако я почти уверен, что иногда быстрый перезапуск VS исправит это, если IISRESET этого не сделает.


0

Visual Studio 2017 отлично справляется с обработкой ошибок. Visual Studio 2015, с другой стороны, отстой при обработке ошибок с задачами, потому что в режиме отладки все исключения, возникающие в асинхронной задаче, перехватываются, но если я перешагну через нее, она просто зависнет на неопределенный срок. Если выполняется без отладки, он зависает на неопределенное время без исключения !!! Я люблю визуальную студию и использую ее с 1995 года, а 2015 год - это, безусловно, худшая версия, хотя я сразу перескочил с 2010 года на 2015 год. Я потратил 8 часов, пытаясь заставить эту обработку исключений работать безуспешно. Я скопировал точный код на 2017 год на свой домашний компьютер, и он отлично сработал. Меня очень раздражает, что Microsoft поместила задачи в фреймворк, с которым компилятор 2015 года не может правильно справиться.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.