Натрапив сьогодні на збірку лінків про всякі цікаві штуки (хочу сказати, автор справді знайшов цікаві теми). Одна з обговорюваних тем (прямий лінк) - як краще передавати шлях до файлу в метод: через FileInfo чи через string?

Для тих хто не хоче перечитувати всі коментарі в темі на StackOverflow, постараюсь стисло передати всю їх суть:

1. як "золоту середину" було запропоновано рішення з 2 методами один з яких приймає string, а інший FileInfo
2. особливо оптимістично налаштовані вирішили, що використання Stream має вирішити  всі проблеми
3. тільки один з учасників читає MSDN :) саме він і запостив, на мою думку, найбільш інформативний коментар ("The difference is primarily that there is a little bit of checking going on; the FileInfo constructor does some checking for a null or clearly invalid parameter...")

Тепер декілька слів по кожному з пунктів:

1. Створювати два методи (які будуть практично ідентичні!) тільки для того щоб всі залишились задоволеними - це якось тупо... і "попахує" добре відомою американською політкоректністю :)
2. у випадку передачі Stream як аргумента без гострої на те необхідності - на кодревю зразу ж потрібно перевіряти справку від психіатра
3. а от почитати MSDN + подивитись Reflector-ом всередину конструктора FileInfo і аргументувати його (не)використання - це досить-таки непогана ідея!

І так, ось що можна побачити всередині конструктора:

[code language="C#"]
        public FileInfo(string fileName)
        {
            if (fileName == null)
            {
                throw new ArgumentNullException("fileName");
            }
            base.OriginalPath = fileName;
            string fullPathInternal = Path.GetFullPathInternal(fileName);
            new FileIOPermission(FileIOPermissionAccess.Read, new string[] {fullPathInternal}, false, false).Demand();
            this._name = Path.GetFileName(fileName);
            base.FullPath = fullPathInternal;
        }
[/code]

Коротке пояснення коду:

• спочатку йде перевірка на null (до речі, в когось є ідеї чому "fileInfo" не перевіряється на пусту строку?) - це ясно
• всередині "Path.GetFullPathInternal(fileName)" проходить валідація шляху до файлу + отримання повного шляху в разі, якщо "fileName" - це відносний шлях  (ага! а от перевірка на пусту строку :) )
• перевірка прав на читання - на мою думку, одна з осносних причин чому варто використовувати FileInfo
• виклик "Path.GetFileName(fileName)" просто перевіряє шлях до файлу на invalid-символи

Як бачимо, нічого надзвичайного :)
Переваги в порівнянні з методом який використовує string-аргумент очевидні:
- "халявна" перевірка шляху на валідність
- перевірка прав перед читанням (про це постійно забувають), а значить можна спростити код обробки помилок в процесі самого читання

Недоліки:
- виклик методу з kernel32 для отрмання повного шляху і перевірка прав доступу займає якийсь час, хоча не думаю що це критично

FYI:
Атрибути і вся інша інформація підгрузиться тільки в момент коли це справді необхідно, тому про додаткові витрати ресурсів хвилюватись не варто.

Як на мене, я бачу більше "плюсів" при використанні FileInfo - додаткові халявні перевірки (в межах розумного) ніколи не бувають лишніми :)

The end

P.S.: Якщо хтось бажає додати "за/проти" кожного з методів, розказати байку про їх використання або просто висказати своє "+1" - прошу в коменти