Throw FileLoadException ou juste IOException

Question

J'écris une application et je veux charger un fichier basé sur un chemin fourni par l'utilisateur. Je vérifie l'extension du fichier et quand l'extension ne correspond à rien, je reconnais que je veux lancer une exception.

Je pourrais lancer un IOException. Mais, j'ai pensé qu'il pourrait y avoir une exception plus détaillée dérivée de cela. J'ai donc regardé MSDN et trouvé FileLoadException. Le nom suggère que mon erreur entrerait dans cette catégorie, mais .... quand je regarde sur MSDN il indique: "Représente l'erreur qui se produit quand un dossier d'Assemblée est trouvé mais ne peut pas être chargé." et "L'exception levée lorsqu'un assembly géré est trouvé mais ne peut pas être chargé." Ce n'est absolument pas ce qui est le cas avec mon erreur.

Alors, quelle est la question alors? Bien, je me demande si la documentation signifie réellement que l'exception est censée être jetée à cet effet seulement ou qu'ils signifient simplement que ils lèvent cette exception dans ce cas spécifique, mais ne spécifient pas vraiment quand d'autres devraient le lancer.

Sur la IOException page sur MSDN, il fait des conseils d'utilisation FileLoadException le cas échéant:

IOException est la classe de base pour les exceptions lancées lors de l'accès des informations en utilisant des ruisseaux, des fichiers et des répertoires.

La bibliothèque de classes de base comprend les types suivants, dont chacun est une classe dérivée de IOException:

• DirectoryNotFoundException
• EndOfStreamException
• FileNotFoundException
• FileLoadException
• PathTooLongException

Le cas échéant, utilisez ces types au lieu de IOException.

CONDENSÉS: Dans le cas d'une extension de fichier inconnu, dois-je jeter un IOException ou un FileLoadException (je ne veux pas définir ma propre exception).

Merci d'avance.

Answer 1

Vous devriez lancer IOException, et ne jamais lancer FileLoadException qui est très spécifique et "technique" (alors que votre exception devrait être "orientée application"). Essayez d'analyser le type FileLoadException avec Reflector (dans mscorlib), vous verrez qu'il n'est utilisé que dans le but défini dans msdn. Alors imaginez un jour votre code utilisé dans un "contexte de plugin", comment réagira le programme hôte attraper un FileLoadException signifiant qu'un assembly n'a pas pu se charger correctement ...

Answer 2

Je ne lancerais pas une exception documentée comme étant un cas d'utilisation très spécifique et qui pourrait dérouter les autres.

Si vous ne pouvez pas définir une nouvelle exception, restez avec IOException.

Answer 3

Il semble qu'il suffit de valider les données de l'utilisateur. Pourquoi voudriez-vous lancer une exception et ne pas informer l'utilisateur qu'il a fourni une extension qui n'est pas reconnue par votre application?

Si vous utilisez le OpenFileDialog, vous pouvez même utiliser le OpenFileDialog.Filter afin de permettre à l'utilisateur de sélectionner uniquement un fichier avec une extension prise en charge par votre application.

Answer 4

FileLoadException ne semble pas être un bon ajustement, car il est spécifiquement pour les assemblages.

IOException est approprié, mais il semble très générique et ne laissera pas les appelants le gérer avec élégance, en le distinguant des erreurs plus générales.

Si vous devez vraiment lancer une exception ici, pensez à NotSupportedException, qui identifie une tentative d'exécution d'une opération que votre objet ne prend pas en charge, dans ce cas le chargement d'un format de fichier que vous ne reconnaissez pas.

Answer 5

Une bonne pratique consiste à définir vos propres exceptions: en tirer une si Exception ou toute autre sous-classe Exception plus spécifique. Cela vous permettra d'économiser du temps lors des tests et de vous fournir plus d'informations avec vos commentaires futurs: vous pouvez différer entre certaines exceptions qui ne sont pas traitées dans votre code et celles que votre propre logique métier déclenche en fonction de vos règles spécifiques.

En parlant de ce cas, je vous conseille de créer FileExtensionException dérivé de IOException. Cela vous facilitera grandement le code: vous n'aurez pas à vérifier le message d'erreur en fournissant un bloc catch distinct pour le nouveau type d'exception.