J'écris une application C # qui utilise l'automatisation pour contrôler un autre programme. Naturellement, ce programme doit être exécuté pour que mon programme fonctionne. Lorsque mon programme recherche la candidature et que je ne trouve pas que je souhaite jeter une exception (pour l'instant plus tard, je pourrais essayer d'ouvrir l'application ou de dire à l'utilisateur à l'ouvrir, ou ...).
Devrais-je mettre en œuvre une exception personnalisée - ou utiliser la note-useredException existante (ou l'une des autres exceptions .NET). Si une exception personnalisée, que suggéreriez-vous? Je pensais à mettre en œuvre une exception personnalisée, je l'appellerais à MyappendieException, puis utilisez simplement le message pour déclarer ce que le problème était?
Y a-t-il des règles générales pour jeter des exceptions d'une manière qui rend votre programme plus lisible et convivial, ou je suis juste en train de donner à cela trop de pensée :)?
Merci!
4 Réponses :
Tout d'abord, définissez hériter de celui-ci avec De cette façon, vous pouvez attraper toutes les exceptions à partir de votre application ou juste spécifiques . Voici un exemple de code qui illustre le concept: < / p> et voici un client myappCustomException en tant que classe de base abstraite.
AppnotFoundCustomException .
try / attraper exemple:
Lors de la dérivation de system.Exception , C'est une bonne pratique pour mettre en œuvre les trois constructeurs communs recommandés . Cela dit, dans la situation décrite dans la question, jetant une exception peut ne pas être la meilleure approche. Voir La réponse par @hans passant.
the Directives-cadres Réservez que j'utilise Indique que vous ne devez créer une exception personnalisée que lorsque la condition d'erreur peut être traitée par programme de manière programmée de manière différente de toutes les exceptions existantes.
Dans votre cas, si vous souhaitez créer une exception personnalisée afin de lancer un programme d'installation en arrière, c'est unique et je pense qu'une exception personnalisée irait bien.
Sinon, quelque chose du system.runtime.interopservices.externalexception Heirarchy peut être approprié.
+1 Pour seulement créer des exceptions personnalisées si vous envisagez de les gérer de manière personnalisée. Si vous pouvez réellement faire quelque chose de programmaticité dans la situation que vous avez décrite, j'irais ensuite avec quel facteur suggérait.
Ouais, vous en faites trop. Rien de bon ne va se passer lorsque vous lancez une exception, toute exception, ce programme ne va pas commencer par magie à courir quand vous le faites. Seules les mauvaises choses peuvent arriver, comme un code attrapant réellement cette exception et d'essayer de continuer. Ou personne ne l'attrape et reçoit une boîte de dialogue de rapport d'erreur Windows. Pourrait aussi bien mettre en place une boîte de message et l'appeler un jour avec environnement.exit ().
Bien sûr, cela pourrait être plus utile pour l'utilisateur si vous démarrez ce programme si vous trouvez que cela ne fonctionne pas.
+1 Je suis d'accord, qu'est-ce que l'exception va vraiment être dans ce cas. Il a 0 valeur.
Vous ne devriez certainement pas utiliser NotSupportedException, comme vous le suggérez, car votre application prend en charge la méthode en question. NotSupporteDException est utilisé lorsqu'une interface ou une classe abstraite est mise en œuvre, mais avec certains membres non mis en œuvre entièrement implémentés car ils n'ont pas de sens dans le contexte (lecture d'un flux de sortie, nettoyant une collection lisonly, etc.).
Une correspondance plus proche est quelque chose de InvalidOperationException, où un membre peut être utilisé, mais pas donné l'état actuel.
Vous dites "application", qui suggère un exécutable plutôt qu'un composant à utiliser par autre chose. Dans ce cas, vous n'allez pas buller l'exception jusqu'au code d'appel (puisqu'il n'y a pas de code d'appel), mais augmentez une boîte de dialogue (pour une application d'interface graphique) ou écrivez à console.Error (pour une application de console). Cela rend probablement que vous allez simplement afficher la valeur de la propriété de message de l'exception ou que vous avez juste besoin du type de classe pour signaler un message particulier. Soit simplement dériver qu'IppnoRunningException d'une exception ou simplement en utilisant une exception directement sera probablement parfaitement bien performer, en fonction duquel des deux que vous trouvez le plus pratique.