Является ли File.Exists вредным?

1

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

Любой вызов IO, такой как чтение файловой системы, может завершиться по нескольким причинам. Строка пути может быть неправильной или файл на самом деле не существует, у вас могут отсутствовать разрешения, у кого-то может быть блокировка, которая блокирует вас. У вас может быть даже другой процесс или другой пользователь в сети, перемещающий файл в миллисекунде между вашим File.Exists и вашим Open.

Даже если вы получаете успешный результат из File.Exists, вы по-прежнему должны приложить свои фактические открытые операторы в блоке try для обработки одного из других возможных режимов отказа. Если я думаю об этом правильно, File.Exists просто убаюкивает вас ложным чувством безопасности, если вы используете его вместо Try (как я уверен, что я имел место в прошлом).

Все это звучит так, будто я должен отказаться от File.Exists и изменить любой существующий код, который я нахожу, чтобы использовать шаблон Try... Catch. Это разумный вывод? Я понимаю, что авторы фреймворка, но это там для нас использовать, но это автоматически не делает его хорошим инструментом на практике.

  • 0
    Если вы, ребята, думаете, что это концептуально и должно быть на Programmers.SE, не стесняйтесь переносить его.
  • 0
    я не думаю, что это вызовет исключение
Показать ещё 3 комментария
Теги:
file-io

4 ответа

4
Лучший ответ

Я думаю, что ответ полностью зависит от ваших конкретных причин использования File.Exists.

Например, если вы проверяете определенный путь к файлу для поступления файла, File.Exists может быть легко подходящим подходом, потому что вам все равно, в чем причина небытия.

Однако, если вы обрабатываете файл, который запросил конечный пользователь (т.е. Импортируйте этот файл excel), вам нужно точно знать, почему файл не сработал. В этом конкретном экземпляре File.Exists не был бы вполне правильным, потому что существование файла могло измениться между временем проверки и временем открытия файла. В этом случае мы пытаемся открыть файл и получить его блокировку до его обработки. Открытый метод выдаст ошибки, соответствующие конкретному сценарию, который вы обрабатываете, чтобы предоставить пользователю более точную информацию о проблеме (т.е. Другой процесс заблокирован файлом, сетевой файл недоступен и т.д.).

3

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

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

3

Я использую File.Exists в тех случаях, когда файл может не существовать при нормальных рабочих условиях (без нарушения в моей системе). Если я знаю, что файл должен существовать (если моя система не разбита), то я не использую File.Exist.

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

0

Это зависит от вас, как вы хотите обрабатывать файл, который не найден. Если вы использовали File.Exists, чтобы проверить, есть ли файл или нет, или вы можете также использовать блок try catch вокруг вашего кода и обрабатывать исключение FilenotFound, это будет определять погоду, когда файл существует или нет. Его чисто до вас, но я бы предпочел проверить File.Exists. Это то же самое, что и проверка null для доступа к объекту, а не запись try catch вокруг вашего блока кода и идентификация в catch, что вы объект null. Всегда полезно обрабатывать такие проверки в конце, а оставлять их на С# try catch block.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню