C# Pragma за потискане на прекъсване при хвърлена грешка

Първо, стартирам приложенията си с изключения, хвърлени при всяка грешка (обработена или не).

Второ, използвам TypeConverter за преобразуване от потребителски въведен низ в действителния обект.

Трето TypeConverter не предлага TryConvert метод, така че съм блокиран да използвам изключения за валидиране, използвайки този доста грозен код тук:

try
{
    this._newValue = null;
#pragma Magic_SuppressBreakErrorThrown  System.Exception
    this._newValue = this.Converter.ConvertFromString(this._textBox.Text);
#pragma Magic_ResumeBreakErrorThrown  System.Exception
    this.HideInvalidNotification();
}
catch (Exception exception)
{
    if (exception.InnerException is FormatException)
    {
        this.ShowInvalidNotification(this._textBox.Text);
    }
    else
    {
        throw;
    }
}

Намирам за доста разсейващо изпълнението на VS break всеки път, когато въвеждам - от -1 или някакъв друг невалиден знак. Бих могъл да използвам нещо подобно на това, но не всички типове, които конвертирам да има и метод TryParse.

Надявам се, че може да има някакъв начин да деактивирам прекъсването на секцията от код в рамките на try, без да променя моите настройки за изключение.


c# pragma exception-handling
person Community    schedule 25.03.2010    source източник
comment
Това е опция за отстраняване на грешки, а не опция за компилатор.   -  person leppie    schedule 25.03.2010

Отговори (4)


arrow_upward
0
arrow_downward

Не съм сигурен, че следвам въпроса ви изцяло, но ако искате да деактивирате прекъсването на VS при конкретни изключения, можете да персонализирате това с помощта на диалоговия прозорец Изключения (ctrl-alt-e). Отворете дървото на Common Language Runtime Exceptions и преминете към конкретното изключение и го изключете. FormatException се намира под System. По този начин VS ще се счупи при всички управлявани изключения с изключение на FormatException.

person Brian Rasmussen    schedule 25.03.2010
comment
Това наистина е ефектът, който търся, за съжаление той хвърля System.Exception, а не FormatException. Надявах се все пак да мога да пробия всички, освен ако не се случи в рамките на изрично определен регион на код (вижте редактиране). - person ; 25.03.2010
comment
Но това изключва всички хвърляния на този вид изключение. Какво ще стане, ако вашата програма потенциално хвърля FormatException на може би 100 места и вие добавяте опит/улов за първото място, но това е в цикъл от 1000 елемента, преди да получи хвърлен някъде другаде. Предполагам, че OP иска да каже, че искам да прекъсна FormatException, хвърлено ОСВЕН когато този ... блок от код го хвърли - person Caius Jard; 27.04.2017

arrow_upward
15
arrow_downward

Поставете try/catch в неговия собствен метод и задайте този атрибут на метода:

[System.Diagnostics.DebuggerNonUserCode]

Дебъгерът няма да спре в този метод (дори за точки на прекъсване). И когато методът е завършен, изключението вече е обработено, така че не прекъсва и в този момент.

person Fantius    schedule 06.03.2011
comment
Добро обаждане, това реши проблема ми (имам стотици места, които ArgumentNull може да хвърли и един е много често, два са много неясни. Като направя този атрибут на мястото, където хвърля често (там вече го обработих), мога да намеря другите места, които хвърля, когато целият логически цикъл има манипулатор за обвиване, благодаря! - person Caius Jard; 27.04.2017
comment
Обърнете внимание, че това не работи за изрази, извиквани чрез LINQ заявка, към която програмата за отстраняване на грешки ще влезе така или иначе. - person Elaskanator; 31.05.2018

arrow_upward
0
arrow_downward

В менюто Debug -> Exceptions можете да изключите прекъсването за всеки конкретен тип изключение.

person Adam Says - Reinstate Monica    schedule 25.03.2010
comment
Но какво ще стане, ако искате логика Искам да прекъсна FormatException, хвърлено ОСВЕН когато този блок от код го хвърли, защото вече го обработих там, така че не ме интересува - искам едно от другите места, които хвърля - person Caius Jard; 27.04.2017
comment
VS 2017 добави условия към прозореца за изключение. Не съм го използвал, така че не знам дали ще се справи със случая, за който говорите, но може да си струва да го разгледате. - person Adam Says - Reinstate Monica; 28.04.2017

arrow_upward
0
arrow_downward

Не е директен отговор, но бихте могли да създадете метод, който прави проверка за разумност на стойностите на низа, преди да се опитате да използвате TypeConverter, и след това да приложите атрибута Conditional("DEBUG") към него - така че производственият код да върви напред и използва TypeConverter (и улавя всички неуспешни случаи), докато по време на отстраняване на грешки, вашите често срещани грешки се избират и избягват, преди да натиснете TypeConverter.

Чрез прилагането на условното условие избягвате изобщо използването на този код в версията на вашия код - той е там само за да улавя често срещаните грешки, които се прокрадват в момента.

person Damien_The_Unbeliever    schedule 25.03.2010