Это - плохо стиль программирования, чтобы иметь сингл, возможно, общее, универсальное исключение?

• пишут "основной" код для обработки ожидаемых случаев.
• написать код обработки исключений , чтобы ... ждать его ... обрабатывать исключительные случаи . Вот почему это называется «кодом обработки исключений». : -)

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

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

Выполнение проверок пути и других проверок не обязательно устраняет необходимость обработки исключений и блоков try. Исключения происходят постоянно (каталог не существует, сеть не подключена) это неожиданные, непредвиденные исключения, для обработки которых предназначены блоки try / catch.

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

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

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

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

Нет правильного ответа. Это действительно зависит от вашего целевого пользовательского опыта.

Вы не должны использовать исключения для управления потоком, потому что это снижает производительность, а исключения не предназначены для этой цели. Вместо этого вы должны протестировать свойство Exists , чтобы убедиться, что каталог существует

Я бы не рекомендовал универсальный обработчик исключений. Вместо этого вам следует найти DirectoryInfo и типы исключений, которые он может генерировать. Затем вы должны попытаться избежать как можно большего числа, прежде чем вызывать конструктор, и перехватить только те исключения, которые вы ожидаете. Итак, мой код будет выглядеть так:

try
{
    if ( string.IsNullOrEmpty( someString ) )
        //do something or throw an exception
    if ( someString.Length > 248 )
        //do something or throw an exception

    DirectoryInfo dirInfo = new DirectoryInfo(someString); 

    If ( !dirInfo.Exists )
        //do something or throw an exception

    //path exists and is valid
    //Some operations here
}
catch(SecurityException)
{
  //Didn't work? great... we will say: somethings wrong, try again/next one
}
catch(ArgumentException)
{
  //Didn't work? great... we will say: somethings wrong, try again/next one
}

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

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

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

Не беспокойтесь о стоимости исключений. По сравнению со стоимостью выполнения операций ввода-вывода стоимость исключения ничтожна.

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