Перерва 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. Поставте позначку " Винятки з загальної мови" .

Це воно!

Мене надихнула ця публікація, оскільки я використовую x64 версію Windows .

Для googler, який хоче вийти з ладу лише тоді, коли виняток стосується їх коду, у Visual Studio 2015 є варіант: Options-> Debugging-> General-> Just My Code. Після перевірки це дозволяє не порушувати, коли виняток керується (кидається та ловиться) поза вашим кодом.

Майкрософт тонко змінив логіку у новому вікні винятків.

Дивіться http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx

Ключова частина:

Важливі примітки

• Це нове вікно містить усі ті ж функціональні можливості, що й старі діалогові вікна модалі. Жодні можливості налагоджувача не змінили лише спосіб доступу до них
• Відладчик завжди буде зламатися, коли виняток буде не оброблено
• Налаштування, яке потрібно змінити, якщо налагоджувач працює на винятки, якими керує користувач, перемістився в контекстне меню
• Місце меню переміщено до Налагодження -> Windows -> Налаштування винятку

Однак якщо у мене, як у мене, у вашому коді є глобальний обробник винятків винятків, то другий пункт у цьому списку є ключовим: для мене жодні винятки не будуть справді обробленими, що, схоже, відрізняється від 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", тоді ви не повинні отримати жодних витягів з розриву для безвідмовної роботи. Ви завжди будете ламатися, якщо виняток буде без змін. Але якщо у вас група CLR не знімається, введіть код всередині спробу ... улов просто не повинен спричиняти перерви. Це НЕ так.

Рішення. У новій панелі інструментів налаштувань винятку клацніть правою кнопкою миші та оберіть "відновити типові". Taadaaaa ... Знову поводиться нормально. Тепер не гнітуйся.

Спробуйте дотримуватися інструкцій:

1. У вікні Налаштування винятку відкрийте контекстне меню, клацнувши правою кнопкою миші у вікні, а потім виберіть Показати стовпці. (Якщо ви вимкнули Just My Code, цю команду ви не побачите.)
2. Ви повинні побачити другий стовпець під назвою Додаткові дії. Цей стовпець відображає Продовжити, коли не обробляється кодом користувача за певними винятками, це означає, що налагоджувач не порушується, якщо цей виняток не обробляється в коді користувача, а обробляється у зовнішньому коді.
3. Ви можете змінити цей параметр або для конкретного винятку (виберіть виняток, клацніть правою кнопкою миші та виберіть / скасувати вибір Продовжити, коли Unhandled в коді користувача), або для цілої категорії винятків (наприклад, всі винятки з загальної мови виконання).

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

Це все трохи заплутано, і на мою думку, не так добре, як старий діалог винятків, але все одно.

Якщо в списку є виняток і поставлено галочку, тоді налагоджувач буде порушений кожного разу, коли викид буде викинуто.

Якщо виняток відмічений або немає у списку, відладчик буде зламатися лише тоді, коли цей тип виключення буде користувачем не оброблений.

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

Коли я перейшов до 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

Після перевірки наш код зробив так, як очікувалося.

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

ви фактично говорите не продовжувати (тобто перервати), коли не обробляєте код

Зробити це:

1. Клацніть правою кнопкою миші виняток або набір винятків, які вас цікавлять (тобто, як правило, верхній рядок "Винятки з загальної мови в роботі" у дереві
2. Оберіть опцію Продовжити, коли не використовується в коді користувача (див. Нижче)
3. Переконайтесь, що винятки не перевірені (див. Нижче)
4. продовжувати налагодження

Це зробив для мене - знову щасливий.

Це було у VS 2015

Однозначно є помилка в Visual Studio, яка може спричинити її застрявання, що вимагає перезавантаження. Навіть VS2015.

У мене була одна різьбова ситуація, коли " NullReferenceExceptionпотрапив" зовнішній "обробник (все ще в моєму коді), хоча я попросив його зламатись, коли він був піднятий.

Я усвідомлюю, що це "оброблений" виняток, і ви говорите про "без обробки", однак я впевнений, що іноді швидкий перезапуск VS це виправить, якщо IISRESET цього не зробить.

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