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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это оно!

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

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

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.

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

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

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

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

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()никогда не проверяется. Если в вашем коде есть аналогичные типы логики «запустил и забыл», вы не увидите исключения в момент их создания (даже если они «не обрабатываются» внутри метода); исключение появляется только тогда, когда вы наблюдаете за Задачей, ожидая ее, проверяя ее Результат или явно просматривая ее Исключение.

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

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

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

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

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

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

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

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

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

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

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

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

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

Это было в VS 2015

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

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

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

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