РЕДАКТИРОВАТЬ: Я согласен с другими, которые говорят, что, начиная с C # 6.0, фильтры исключений теперь идеально подходят: catch (Exception ex) when (ex is ... || ex is ... )
За исключением того, что я все еще ненавижу макет из одной длинной строки и лично выложил бы код следующим образом. Я считаю, что это так же функционально, как и эстетично, поскольку я считаю, что это улучшает понимание. Некоторые могут не согласиться:
catch (Exception ex) when (
ex is ...
|| ex is ...
|| ex is ...
)
ОРИГИНАЛ:
Я знаю, что немного опаздываю на вечеринку здесь, но святой дым ...
Переходя прямо к делу, этот вид дублирует предыдущий ответ, но если вы действительно хотите выполнить общее действие для нескольких типов исключений и сохранить все это аккуратно и аккуратно в рамках одного метода, почему бы просто не использовать лямбда / closure / inline, чтобы сделать что-то вроде следующего? Я имею в виду, что велики шансы, что вы в конечном итоге поймете, что просто хотите сделать это закрытие отдельным методом, который можно использовать повсюду. Но тогда это будет очень легко сделать без фактического изменения остальной части кода структурно. Верно?
private void TestMethod ()
{
Action<Exception> errorHandler = ( ex ) => {
// write to a log, whatever...
};
try
{
// try some stuff
}
catch ( FormatException ex ) { errorHandler ( ex ); }
catch ( OverflowException ex ) { errorHandler ( ex ); }
catch ( ArgumentNullException ex ) { errorHandler ( ex ); }
}
Я не могу не задаться вопросом (предупреждение: впереди небольшая ирония / сарказм), зачем тратить столько усилий, чтобы просто заменить следующее:
try
{
// try some stuff
}
catch( FormatException ex ){}
catch( OverflowException ex ){}
catch( ArgumentNullException ex ){}
... с какой-то сумасшедшей вариацией запаха следующего кода, я имею в виду пример, только для того, чтобы притвориться, что вы экономите несколько нажатий клавиш.
// sorta sucks, let's be honest...
try
{
// try some stuff
}
catch( Exception ex )
{
if (ex is FormatException ||
ex is OverflowException ||
ex is ArgumentNullException)
{
// write to a log, whatever...
return;
}
throw;
}
Потому что он определенно не становится более читаемым автоматически.
Конечно, я оставил три идентичных экземпляра /* write to a log, whatever... */ return;
из первого примера.
Но это вроде как моя точка зрения. Вы все слышали о функциях / методах, верно? Шутки в сторону. Напишите общую ErrorHandler
функцию и, например, вызовите ее из каждого блока catch.
Если вы спросите меня, второй пример (с ключевыми словами if
и is
) значительно менее читабелен и одновременно значительно более подвержен ошибкам на этапе сопровождения вашего проекта.
Фаза обслуживания для любого, кто может быть относительно новичком в программировании, составит 98,7% или более от общего срока службы вашего проекта, и бедняга, выполняющий обслуживание, почти наверняка будет кем-то другим, а не вами. И есть очень большая вероятность, что они будут тратить 50% своего времени на работе, проклиная ваше имя.
И, конечно же, FxCop лает на вас, поэтому вы должны также добавить в свой код атрибут, который имеет именно zip-архив, связанный с запущенной программой, и служит только для того, чтобы сообщить FxCop игнорирует проблему, которая в 99,9% случаев полностью корректна при пометке. И, извините, я могу ошибаться, но разве этот атрибут ignore не компилируется в ваше приложение?
Может ли размещение всего if
теста в одной строке сделать его более читабельным? Я так не думаю. Я имею в виду, как-то давно у меня был другой программист, который яростно утверждал, что размещение большего количества кода в одной строке заставит его работать быстрее. Но, конечно, он был безумным бредом. Пытаться объяснить ему (с невозмутимым лицом - что было сложно), как интерпретатор или компилятор разбил бы эту длинную строку на отдельные инструкции по одной инструкции на строку - по сути, идентичный результату, если бы он пошел вперед и просто сделал код читабельным, вместо того, чтобы пытаться перехитрить компилятор - на него это никак не повлияло. Но я отвлекся.
Насколько это станет менее читабельным, если вы добавите еще три типа исключений через месяц или два? (Ответ: становится много менее читаемым).
На самом деле, одним из основных моментов является то, что основная цель форматирования текстового исходного кода, на который мы все смотрим каждый день, - сделать это действительно, действительно очевидным для других людей, что на самом деле происходит при выполнении кода. Потому что компилятор превращает исходный код во что-то совершенно другое, и ему наплевать на ваш стиль форматирования кода. Так что все на одной линии тоже полный отстой.
Просто говорю...
// super sucks...
catch( Exception ex )
{
if ( ex is FormatException || ex is OverflowException || ex is ArgumentNullException )
{
// write to a log, whatever...
return;
}
throw;
}
person
Craig
schedule
12.10.2013
AggregateException
: Создание исключения AggregateException в моем собственном коде - person DavidRR   schedule 14.08.2014System.Exception
, это неправильно, для этого есть очень веские причины, не рекомендуется только ловитьSystem.Exception
- person DreadedEntity   schedule 07.07.2021