File.Exists peut-il lever une exception?

Il n'y a pas d'exceptions répertoriées dans la documentation pour cette méthode, ce qui implique qu'aucune exception ne doit être levée. En fait, plus bas, il mentionne que "false" sera renvoyé si une exception aurait été lancée en essayant d'accéder au fichier.

Oui, cela peut générer des exceptions.

Par exemple: OutOfMemoryException .

Ce type d'exception peut ne pas être levé par le code lui-même, mais peut être levé comme un effet secondaire de son exécution.

Il en va de même pour la tristement célèbre StackOverflowException, ou aussi, d'autres exceptions de bas niveau peut-être dues à un matériel défaillant.

Je ne connais pas la liste totale; mais je suis sûr; appeler le code peut entraîner la levée d'exceptions.

Comme le note @Otis: il sera difficile de se remettre de ce genre d'exceptions. Donc, même s'ils sont surélevés: souvent un try / catch ne sera pas suffisant.

Donc, pour résumer:

Un appel à File.Exists peut-il entraîner une exception?

Oui

En d'autres termes, dois-je l'envelopper dans un try / catch?

Une autre question, mais probablement pas.

Tout peut entraîner une exception. Même si le code lui-même n'en lance pas un, que faire si vous rencontrez une exception fatale comme OutOfMemory ou ThreadAborted?

Cela semble être principalement une question sur la gestion des exceptions, et pour ces questions, j'ai deux articles que je lie souvent:

• https://blogs.msdn.microsoft.com / ericlippert / 2008/09/10 / vexing-exceptions /
• https://www.codeproject.com/ Articles / 9538 / Bonnes pratiques de gestion des exceptions dans NET

Si vous voulez apprendre à gérer les exceptions, c'est un très bon début.

Non, selon le code source a >:

    // Determine whether path describes an existing directory
    // on disk, avoiding security checks.
    [System.Security.SecurityCritical]  // auto-generated
    [ResourceExposure(ResourceScope.Machine)]
    [ResourceConsumption(ResourceScope.Machine)]
    internal static bool InternalExists(String path, out int lastError) {
        Win32Native.WIN32_FILE_ATTRIBUTE_DATA data = new Win32Native.WIN32_FILE_ATTRIBUTE_DATA();
        lastError = File.FillAttributeInfo(path, ref data, false, true);

        return (lastError == 0) && (data.fileAttributes != -1)
                && ((data.fileAttributes & Win32Native.FILE_ATTRIBUTE_DIRECTORY) != 0);
    }

EDIT: Comme je ne peux pas trouver le code source de FileSystem.FileExists , j'ai vérifié le . NET Framework code source à la place, c'est un peu différent lors de l'appel interne:

    // Tests whether a file exists. The result is true if the file
    // given by the specified path exists; otherwise, the result is
    // false.  Note that if path describes a directory,
    // Exists will return true.
    public static bool Exists(string path)
    {
        try
        {
            if (path == null)
                return false;
            if (path.Length == 0)
                return false;

            path = Path.GetFullPath(path);

            // After normalizing, check whether path ends in directory separator.
            // Otherwise, FillAttributeInfo removes it and we may return a false positive.
            // GetFullPath should never return null
            Debug.Assert(path != null, "File.Exists: GetFullPath returned null");
            if (path.Length > 0 && PathInternal.IsDirectorySeparator(path[path.Length - 1]))
            {
                return false;
            }

            return FileSystem.FileExists(path);
        }
        catch (ArgumentException) { }
        catch (IOException) { }
        catch (UnauthorizedAccessException) { }

        return false;
    }

Il appelle à son tour FillAttributeInfo (le code est un peu long donc je ne le colle pas ici), je pense qu'il ne lance que IOException (à la ligne 1402 __Error .WinIOError (); )