Lors de la levée d'une exception?

Mon orientation est: une exception est levée lors d'une hypothèse fondamentale de l'actuel bloc de code est fausse.

Exemple 1: dire que j'ai une fonction qui est censé examiner arbitraire de la classe et retourne true si cette classe hérite de la Liste<>. Cette fonction pose la question, "cet objet Est-il un descendant de la Liste?" Cette fonction ne doit jamais lever une exception, car il n'existe pas de zones grises, dans son fonctionnement, chaque classe ou de ne pas hériter de la Liste<>, donc la réponse est toujours "oui" ou "non".

Exemple 2: dire que j'ai une autre fonction qui examine une Liste<>, et retourne true si sa longueur est de plus de 50, et false si la longueur est de moins en moins. Cette fonction pose la question, "est-ce que cette liste ont plus de 50 articles?" Mais cette question fait une hypothèse, il suppose que l'objet auquel il est donné une liste. Si j'ai la main un NUL, alors que l'hypothèse est fausse. Dans ce cas, si la fonction renvoie soit true ou false, c'est la rupture de ses propres règles. La fonction ne peut pas retourner tout et de prétendre qu'il a répondu correctement à la question. Donc, il n'est pas de retour, il lève une exception.

Ceci est comparable à la "question piège" erreur de logique. Chaque fonction pose une question. Si l'entrée est donné fait de cette question une erreur, puis lancer une exception. Cette ligne est plus difficile que de dessiner avec des fonctions qui retourne void, mais la ligne de fond est la suivante: si la fonction d'hypothèses sur ses entrées sont violés, il doit lever une exception, au lieu de retourner normalement.

L'autre côté de cette équation est: si vous trouvez que vos fonctions de lever des exceptions fréquemment, alors vous avez probablement besoin d'affiner leurs hypothèses.

Mon petit directives sont fortement influencés par le grand livre "Code complete":

• Utiliser les exceptions pour les informer au sujet des choses qui ne devraient pas être ignorée.
• N'utilisez pas des exceptions si l'erreur peut être gérée localement
• Assurez-vous que les exceptions sont au même niveau d'abstraction que le reste de votre routine.
• Exceptions doivent être réservés pour ce qui est vraiment exceptionnelle.

Une règle de base est d'utiliser des exceptions dans le cas de quelque chose que vous ne pourriez normalement pas prédire. Des exemples sont connectivité de base de données, fichier manquant sur le disque, etc. Pour les scénarios que vous pouvez prédire, c'est à dire les utilisateurs essayant de se connecter avec un mot de passe incorrect, vous devriez être en utilisant les fonctions qui retournent des valeurs booléennes et de savoir comment gérer la situation correctement. Vous ne voulez pas brusquement fin de l'exécution par la levée d'une exception juste parce que quelqu'un fait une faute de frappe leur mot de passe.

Exceptions sont un peu coûteux effet, si par exemple vous avez un utilisateur qui fournit un mot de passe invalide, il est généralement une meilleure idée de passer de nouveau un échec drapeau, ou tout autre indicateur qu'il est invalide.

Cela est dû à la façon dont les exceptions sont gérées, véritable mauvaise entrée, et unique arrêt critique les articles doivent être des exceptions, mais pas de connexion a échoué info.

Je dirais il n'y a pas de règles strictes sur l'utilisation des exceptions. Cependant, il existe de bonnes raisons pour utiliser ou de ne pas les utiliser:

Raisons de l'utilisation d'exceptions:

• Le flux de code pour le cas courant est plus clair
• Pouvez retourner complexe d'erreur de l'information comme un objet (même si cela peut également être réalisé à l'aide d'erreur "out" paramètre passé par référence)
• Langues généralement fournir une certaine facilité pour la gestion ordonnée de nettoyage dans le cas de l'exception (try/finally en Java, en C#, RAII en C++)
• Dans le cas où aucune exception est levée, l'exécution peut parfois être plus rapide que la vérification des codes de retour
• En Java, vérifié les exceptions doivent être déclarés ou pris (même si cela peut être une raison contre)

Raisons de ne pas utiliser les exceptions:

• Parfois c'est exagéré si l'erreur de manipulation est simple
• Si les exceptions ne sont pas documentés ou déclarés, ils peuvent être interceptée par le code appelant, ce qui peut être pire que si le code appelant simplement ignoré un code de retour (demande de sortie vs échec silencieux - ce qui est le pire peut dépendre du scénario)
• En C++, le code qui utilise les exceptions doivent être d'exception coffre-fort (même si vous n'avez pas les jeter ou de les attraper, mais appeler un lancement en fonction indirectement)
• En C++, il est difficile de dire quand une fonction peut-être jeter, donc vous devez être paranoïaque à propos de l'exception de sécurité si vous les utilisez
• Lancer et attraper les exceptions est généralement beaucoup plus cher par rapport à la vérification d'un indicateur de retour

En général, je serais plus enclin à utiliser les exceptions en Java qu'en C++ ou C#, parce que je suis de l'avis qu'une exception, déclarée ou non, est fondamentalement partie de l'interface formelle d'une fonction, puisque la modification de votre exception de garantie peut casser le code appelant. Le plus grand avantage de les utiliser en Java de l'OMI, c'est que vous savez que votre interlocuteur DOIT gérer l'exception, et cela améliore les chances de corriger son comportement.

De ce fait, dans n'importe quelle langue, je serais toujours tirer toutes les exceptions dans une couche de code ou de l'API à partir d'une même classe, de sorte que le code appelant peut toujours garantir à attraper toutes les exceptions. Aussi je pense qu'il serait mauvais pour jeter l'exception des classes qui sont spécifiques à l'implémentation, lors de l'écriture d'une API ou d'une bibliothèque (c'est à dire envelopper les exceptions de la baisse des couches de sorte que l'exception que votre interlocuteur reçoit est compréhensible dans le contexte de votre interface).

Noter que Java fait la distinction entre le général et l'Exécution des exceptions en ce que ce dernier n'a pas besoin d'être déclarée. Je tiens seulement à l'utilisation d'Exécution des classes d'exception lorsque l'on sait que l'erreur est le résultat d'un bug dans le programme.

Si c'est le code s'exécute à l'intérieur d'une boucle qui entraînera probablement une exception, encore et encore, puis de lever des exceptions n'est pas une bonne chose, car ils sont assez lents pour les grandes N. Mais il n'y a rien de mal à jeter personnalisé des exceptions si la performance n'est pas un problème. Assurez-vous juste que vous avez une base d'exception qu'ils ont tous inherite, appelé BaseException ou quelque chose comme ça. BaseException hérite du Système.Exception, mais l'ensemble de vos exceptions héritent BaseException. Vous pouvez même avoir un arbre d'Exception types de groupe de types similaires, mais cela peut ou peut ne pas être exagéré.

Donc, la réponse courte est que si cela ne cause pas de perte de performances significatives (ce qui ne devrait pas, sauf si vous êtes lancer beaucoup d'exceptions), puis aller de l'avant.

la règle de base pour lancer des exceptions est assez simple. vous le faites lorsque votre code est entré dans une IRRÉMÉDIABLE état non VALIDE. si des données est compromise ou que vous ne pouvez pas revenir en arrière le traitement qui en sont produites jusqu'à ce point, alors vous devez y mettre fin. en effet, quoi d'autre pouvez-vous faire? votre logique de traitement finira par échouer ailleurs. si vous pouvez le récupérer en quelque sorte, puis faire et ne pas jeter l'exception.

dans votre cas particulier, si vous avez été forcé de faire quelque chose de stupide comme accepter le retrait d'argent et seulement ensuite, vérifiez d'utilisateur/mot de passe, il faut arrêter le processus en levant une exception pour avertir que quelque chose de mauvais s'est passé et prévenir d'autres dommages.

Tout d'abord, si les utilisateurs de votre API ne sont pas intéressés en particulier, à grain fin échecs, puis d'avoir des exceptions spécifiques pour eux n'est d'aucune valeur.

Car il est souvent impossible de savoir ce qui peut être utile pour vos utilisateurs, une meilleure approche est d'avoir les exceptions spécifiques, mais de s'assurer qu'ils héritent d'une classe commune (par exemple, std::exception ou de ses dérivés en C++). Qui permet à votre client pour attraper les exceptions spécifiques s'ils le souhaitent, ou plus générale, à l'exception si elles n'avez pas de soins.

J'ai des problèmes philosophiques avec l'utilisation d'exceptions. Fondamentalement, vous vous attendez à un scénario spécifique, mais plutôt que de le manipuler explicitement vous appuyez sur le problème de congé pour être manipulés "ailleurs". Et où cet "ailleurs", c'est peut être n'importe qui conjecture.

la raison principale pour éviter de lancer une exception est qu'il y a beaucoup de frais généraux impliqués avec la levée d'une exception.

Une chose que l'article ci-dessous est qu'une exception est une des conditions exceptionnelles et des erreurs.

Un mauvais nom d'utilisateur n'est pas nécessairement une erreur de programme, mais une erreur de l'utilisateur...

Ici est un bon point de départ pour des exceptions à l'intérieur .NET:
http://msdn.microsoft.com/en-us/library/ms229030(SV.80).aspx

J'ai trois types de conditions que j'ai prises.

1. Incorrect ou manquant d'entrée ne doit pas être une exception. Utiliser à la fois côté client et js côté serveur regex pour détecter, des attributs et de l'arrière vers l'avant à la même page avec les messages.

2. La AppException. C'est généralement une exception que vous le détecter et de le jeter dans votre code. En d'autres termes ce sont ceux que vous attendez (le fichier n'existe pas). Journal, il suffit de mettre le message, et de l'arrière vers l'avant à l'erreur générale de la page. Cette page a habituellement un peu d'info sur ce qui s'est passé.

3. L'Exception inattendue. Ce sont ceux que vous ne connaissez pas. Journal avec les détails et de les transférer à un général page d'erreur.

Espère que cette aide

La réponse est simple, chaque fois qu'une opération est impossible (à cause de l'application OU parce que cela serait contraire à la logique d'entreprise). Si une méthode est invoquée et qu'il est impossible de faire ce que la méthode a été écrit pour faire, de lever une Exception. Un bon exemple est que les constructeurs lancent toujours ArgumentExceptions si une instance ne peut pas être créé à l'aide des paramètres fournis. Un autre exemple est InvalidOperationException, qui est générée lorsqu'une opération ne peut pas être effectuée en raison de l'état d'un autre membre ou à des membres de la classe.

Dans votre cas, si la méthode Login(nom d'utilisateur, mot de passe) est invoquée, si le nom d'utilisateur n'est pas valide, il est juste à un jet de UserNameNotValidException, ou PasswordNotCorrectException si le mot de passe est incorrect. L'utilisateur ne peut pas être connecté à l'aide du paramètre fourni(s) (c'est à dire que c'est impossible parce que cela serait contraire à l'authentification), afin de lever une Exception. Bien que je pourrais avoir vos deux Exceptions héritent de ArgumentException.

Cela dit, si vous souhaitez ne PAS lever une Exception si un échec de connexion peut être très commun, une stratégie consiste à créer à la place une méthode qui retourne les types qui représentent les différents échecs. Voici un exemple:

{ //class
    ...

    public LoginResult Login(string user, string password)
    {
        if (IsInvalidUser(user))
        {
            return new UserInvalidLoginResult(user);
        }
        else if (IsInvalidPassword(user, password))
        {
            return new PasswordInvalidLoginResult(user, password);
        }
        else
        {
            return new SuccessfulLoginResult();
        }
    }

    ...
}

public abstract class LoginResult
{
    public readonly string Message;

    protected LoginResult(string message)
    {
        this.Message = message;
    }
}

public class SuccessfulLoginResult : LoginResult
{
    public SucccessfulLogin(string user)
        : base(string.Format("Login for user '{0}' was successful.", user))
    { }
}

public class UserInvalidLoginResult : LoginResult
{
    public UserInvalidLoginResult(string user)
        : base(string.Format("The username '{0}' is invalid.", user))
    { }
}

public class PasswordInvalidLoginResult : LoginResult
{
    public PasswordInvalidLoginResult(string password, string user)
        : base(string.Format("The password '{0}' for username '{0}' is invalid.", password, user))
    { }
}

La plupart des développeurs sont appris à éviter les Exceptions en raison de la surcharge causée par les jeter. C'est génial d'être conscient, mais généralement pas au détriment de la conception de votre application. C'est probablement la raison qui vous a dit de ne pas jeter vos deux Exceptions près. Si l'utilisation des Exceptions ou non arrête généralement à la fréquence de l'Exception se produit. Si c'est un assez commun ou assez prévisible résultat, c'est quand la plupart des développeurs va éviter les Exceptions et créer à la place une autre méthode pour indiquer l'échec, en raison de la prétendue consommation de ressources.

Voici un exemple d'éviter l'utilisation des Exceptions dans un scénario comme vient de le décrire, à l'aide de l'Essayer() motif:

public class ValidatedLogin
{
    public readonly string User;
    public readonly string Password;

    public ValidatedLogin(string user, string password)
    {
        if (IsInvalidUser(user))
        {
            throw new UserInvalidException(user);
        }
        else if (IsInvalidPassword(user, password))
        {
            throw new PasswordInvalidException(password);
        }

        this.User = user;
        this.Password = password;
    }

    public static bool TryCreate(string user, string password, out ValidatedLogin validatedLogin)
    {
        if (IsInvalidUser(user) || 
            IsInvalidPassword(user, password))
        {
            return false;
        }

        validatedLogin = new ValidatedLogin(user, password);

        return true;
    }
}

pour moi une Exception doit être levée lorsque requis techniques ou des affaires d'échec de la règle.
par exemple, si une voiture entité est associée à la matrice de 4 pneus ... si l'on tire ou plus sont nulles ... une exception devrait être Congédié "NotEnoughTiresException" , car il peut être pris à différents niveaux du système et avoir un grand sens grâce à la consignation.
en outre, si nous essayons juste de flux de contrôle de la valeur null et empêcher l'instanciation de la voiture .
nous pourrions ne jamais ne jamais trouver la source du problème , parce que le pneu n'est pas censé être null dans la première place .

Finalement, la décision revient à savoir s'il est plus utile de traiter au niveau de l'application des erreurs comme ceci en utilisant la gestion des exceptions, ou par l'intermédiaire de votre propre maison laminé mécanisme comme le retour des codes d'état. Je ne pense pas qu'il y a un dur et rapide de la règle sur ce qui est mieux, mais je considère:

• Qui appelle votre code? Est-ce une API publique de quelque sorte ou une bibliothèque interne?
• Quelle langue utilisez-vous? Si c'est de Java, par exemple, puis jetant un (vérifié) exception met explicitement un fardeau sur votre appelant à gérer cette condition d'erreur, d'une certaine façon, par opposition à un état de retour qui peut être ignorée. Qui pourrait être bon ou mauvais.
• Comment sont les autres conditions d'erreur dans la même application sont-elles traitées? Les appelants ne voulez pas traiter avec un module qui gère les erreurs d'une singulière façon, contrairement à tout le reste du système.
• Combien de choses peuvent mal se passer avec la routine en question, et comment seraient-ils traités différemment? Considérez la différence entre une série de blocs catch qui gèrent les différentes erreurs et un commutateur sur un code d'erreur.
• Avez-vous des informations structurées sur l'erreur que vous avez besoin de revenir? Lancer une exception vous donne un meilleur endroit pour mettre cette information que le juste retour d'un état.

Quelques choses à penser au moment de décider si une exception est le cas:

1. quel est le niveau de code que vous voulez être exécutée après l'exception candidat se produit - qui est, combien de couches de la pile d'appel devrait se détendre. En général, vous voulez gérer une exception aussi près que possible de l'endroit où il se produit. Pour le nom d'utilisateur/mot de passe de validation, vous le feriez normalement gérer les défaillances dans le même bloc de code, plutôt que de laisser une exception de la bulle vers le haut. Si une exception est probablement pas approprié. (Otoh, que, après trois tentatives infructueuses de connexion, flux de contrôle peut se déplacer ailleurs, et une exception peut être approprié ici.)

2. Est cet événement quelque chose que vous voulez voir dans un journal d'erreur? Pas chaque exception est écrit dans un journal d'erreur, mais il est utile de se demander si cette entrée dans un journal d'erreur serait utile - c'est à dire, vous essayez de faire quelque chose à ce sujet, ou serait les ordures que vous ignorer.

Les exceptions et retourner le code d'erreur d'argument devrait être d'environ de contrôle de flux non la philosophie (façon "exceptionnelle" une erreur est):

void f1() throws ExceptionType1, ExceptionType2 {}

void catchFunction() {
  try{
    while(someCondition){
      try{
        f1(); 
      }catch(ExceptionType2 e2){
        //do something, don't break the loop
      }
    }
  }catch(ExceptionType1 e1){
    //break the loop, do something else
  }

}

Ici sont mes suggestions:

Je ne pense pas que c'est TOUJOURS un bon moyen de lever une exception, car il faudra plus de temps, de mémoire pour traiter avec de telles exceptions.

Dans mon esprit, si quelque chose peut être traitée avec un "gentil,poli" façon (cela signifie que si nous pouvons "prédicat de telles erreurs à l'aide des si...... ou quelque chose de ce genre), nous devrions ÉVITER d'utiliser des "exceptions", mais juste de retour d'un indicateur comme "faux" , avec une enveloppe extérieure valeur du paramètre de dire à lui/elle de l'détaillée de la raison.

En est un exemple, on peut faire une classe comme ce qui suit:

public class ValueReturnWithInfo<T>
{
   public T Value{get;private set;}
   public string errorMsg{get;private set;}
   public ValueReturnWithInfo(T value,string errmsg)
   {
      Value = value;
      errMsg = errmsg;
   }
}

Nous pouvons utiliser ces multiples "valeur renvoyée" classes plutôt que des erreurs, ce qui semble être une meilleure,façon polie de processus, à l'exception des problèmes.

Toutefois, notez que si certaines erreurs ne peuvent pas être décrites de manière facilement (cela dépend de votre expérience de la programmation) avec des "si"......(comme FileIO exceptions), vous devez jeter des exceptions.