existe-t-il un moyen de décorer une méthode qui fera une certaine journalisation, puis lancez une exception inconditionnellement, en tant que tel?
J'ai un code comme celui-ci: p>
void foo(out int x)
{
if( condition() ) { x = bar(); return; }
// compiler complains about x not being set yet
MyMethodThatAlwaysThrowsAnException( "missed something." );
}
7 Réponses :
Si vous savez que l'exception sera toujours lancée, pourquoi cela compte-import? Il suffit de définir la variable pour quelque chose afin qu'il puisse compiler:
C'est exactement la chose que je voulais éviter de faire. :)
Cela ne répond pas à votre question, mais lorsque vous utilisez des paramètres, il est toujours judicieux de les initialiser au début de la méthode. De cette façon, vous n'aurez aucune erreur de compilateur:
Je pense que les paramètres doivent être affectés lorsqu'il est logique ou que cela peut empêcher certains bugs cachés lors de la compilation, simplement parce que vous avez oublié d'attribuer un paramètre à un chemin de code.
x est un paramètre out> et doit être défini avant d'aller de l'avant
Sauf si une exception est lancée
C'est toujours une bonne politique de veiller à ce que tout paramètre soit défini tôt dans la méthode et qui leur attribue des défaillants, sinon.
Il n'y a aucun moyen de marquer une méthode de cette manière.
éventuellement non pertinent, mais le motif de votre exemple, à l'aide d'un paramètre code> out>, est un peu impair. Pourquoi pas seulement avoir un type de retour sur la méthode à la place? P>
int Foo()
{
if (condition()) return bar();
MyMethodThatAlwaysThrowsAnException("missed something.");
}
C'était juste un exemple simple. Le code actuel est plutôt plus complexe.
@ k0dek0mmand0: Je soupçonnai que ce soit le cas. Je suppose que vous avez mal de chance - il n'y a aucun moyen de dire au compilateur que mymetthodthalwaysthrowrowrowrowrowrowrowrowrowrowstion toujours.
à quoi ça se passe?
Si vous ne voulez pas avoir à définir x, pourquoi n'utilisez-vous pas simplement un paramètre ref / XXX
C'est un très vieux fil, mais je veux juste ajouter que vous devez l'écrire différent de la start:
void foo(out int x)
{
if (!condition())
MyMethodThatAlwaysThrowsAnException("missed something.");
x = bar();
// and so on...
}
Le code actuel est probablement plus complexe, de sorte que votre suggestion peut ne pas avoir de sens.
Quel problème obtenez-vous?
"x a l'attribut OUT et n'a pas encore été défini à la fin de la méthode"
Je suis confus - comment est-il jeté inconditionnellement s'il n'est pas lancé lorsque X est défini (et un retour est fait)
Je veux marquer mymethodhalwaysthrowrowrowrowrowrowsThrowrowsTthrowrowrowaThrowsThrowsThrowsThrowe, qui jette toujours une exception, pas la méthode FOO.
Je me demande où cette réponse avec la clause de garde est allée. Je pensais que c'était une meilleure réponse pour simplement inverser la logique.
Pourquoi utiliser un paramètre OUT au lieu d'une valeur de retour?
Il veut probablement être un lancer commun au lieu de dupliquer le code pour une valeur non définie. Mais c'est ma supposition. (Les gens doivent se remettre leur chemin n'est pas le seul moyen)
Si je comprends bien cela correctement, vous essayez de refactoriser le code dupliqué car il s'agit d'un modèle que vous utilisez dans plusieurs endroits. Au lieu de
journal ("manqué quelque chose"); jeter une nouvelle exception ("" manquée quelque chose ") Vous voulez un seul appel de méthode.@Greg: quelque chose comme ça. Je veux aussi ajouter une déclaration de débogueur.break dans le mythrow comme je le trouve commode.
Est-ce que cela répond à votre question? Déclarer une méthode jette toujours une exception?