Comment attraper une entrée non valide en c++?

Je suis (un peu) connu python programmeur d'essayer de migrer vers C++. Je veux être capable d'attraper entrée utilisateur non valide. Par exemple, si une variable nécessite un entier, et que l'utilisateur saisit une chaîne de caractères, je veux rattraper cette erreur. En python 3, la syntaxe est la suivante:

try:
    #block of code you want to run
except ValueError:
    #Block of code to be run if the user inputs an invalid input

En c++, j'ai lu que la syntaxe est Try, catch. Je suis en train de le faire, mais sa ne fonctionne pas. voici mon code en c++:

#include "Calculator.h"
#include <iostream>
#include <exception>

using namespace std;

Calculator::Calculator()
{
}

int Calculator::Calc()
{
    cout << "Enter a number " << endl;
try
{
    cin >> a;
}
catch (logic_error)
{
    cout << "An error has ocurred! You have entered an invalid input!"
}

Comment puis-je attraper une entrée non valide en c++? Oui, je suis en utilisant un fichier d'en-tête pour cette classe. Si vous avez besoin de ces matières, laissez-moi savoir. Je vais continuer à chercher sur le web et après si j'ai trouvé une réponse!

  • Je ne voudrais pas utiliser les exceptions pour valider la saisie de l'utilisateur. Je voudrais choisir la méthode de conversion appropriée pour, disons, de string en int, et le message que l'utilisateur en cas d'échec de la validation, puis reprompt pour l'entrée.
InformationsquelleAutor JohnBobSmith | 2013-10-31
  1. 3

    Vous aurez besoin de #include <limits>

    int x;
std::cout << "Enter a number: ";
std::cin >> x;
while(std::cin.fail()) {
    std::cin.clear();
    std::cin.ignore(numeric_limits<streamsize>::max(),'\n');
    std::cout << "Bad entry.  Enter a NUMBER: ";
    std::cin >> x;
}
std::cout << "x = " << x << std::endl;

    Il y a un modèle pour vous.

    • Je vous remercie de votre réponse, un modèle est ce que je cherchais! Cependant, pourquoi dois-je std:: dans le code? Im actuellement plus d'erreurs, voici le code mis à jour à: sharetext.org/FMJr
    • Dans votre cas, vous n'aurez pas, à cause de la ligne using namespace std;. Vous pouvez omettre chaque occurrence de std:: de ma réponse aussi longtemps que vous êtes using namespace std;, mais les gens vont vous dire using namespace std; est une mauvaise pratique.
    • veuillez voir le mon au-dessus de modifier. Im obtenir certaines erreurs, mon code est disponible à l'adresse sharetext.org/FMJr
    • Voici les erreurs im obtenir lorsque j'essaie de compiler le code ci-dessus: erreur: 'numberic_limits' n'a pas été déclarée dans ce champ... erreur: attendu primary-expression before '>' token... error: no matching function for call to 'max{}'
    • Mmm, je pense que vous devrez peut-être #include <limits>
    • Sujet résolu, en ajoutant #include <limits> rendu le code du travail. Une chose cependant. pourquoi est-using namespace std; considéré comme une mauvaise pratique?
    • Je ne suis pas à l'aise de donner une explication complète sur ce que je n'ai pas 100% de la comprendre. Mais une rapide recherche sur Google va probablement des StackOverflow postes où il a été discuté.
    • l'espace de noms std est aussi mauvais que from Foo import * chaque fois que vous importez un module. Finalement, vous obtiendrez un conflit de nom, appelez la fonction incorrecte, etc. À l'aide de std:: partout, c'est souvent trop lourde, de sorte qu'un bon équilibre est à using namespace std; seulement à l'intérieur des fonctions, ou using std::cin; using std::cout sélective de porter des noms à l'espace de noms global.

    InformationsquelleAutor nhgrif
  2. 4

    Par défaut, C++ ruisseaux, ne pas jeter sur mal formée d'entrée: il n'est pas exceptionnel que l'entrée est incorrect. Il est normal. Le C++ approche à indiquer d'entrée de l'échec est de mettre le ruisseau en état d'échec, c'est à dire, pour définir l'état du pavillon std::ios_base::failbit. La façon la plus simple pour tester la saisie erronée est d'utiliser quelque chose comme

    if (in >> value) {
    process(value);
}
else {
    deal_with_input_error(in);
}

    Traitant de l'erreur de saisie généralement les montants de compensation du ruisseau de l'état (tant que c'est des modes de défaillance et de ne pas traiter le flux réel) et ensuite à ignore() un ou plusieurs de la délinquance caractères.

    Si vous voulez vraiment obtenir une exception, vous pouvez définir un masque d'exception:

    in.exceptions(std::ios_base::failbit);
try {
    in >> value;
}
catch (std::ios_base::failure const& ex) {
    //deal with the error
}

    Chaque fois que in.exceptions() & in.rdstate() est non-zéro à la fin de l'un des membres concernant l'état des bits ou le masque d'exception est appelé une exception (c'est à dire l'appel de in.exception(std::ios_base::failbit) peut lever une exception). L'exception est de type std::ios_base::failure.

    Je recommande pas d'utiliser l'exception des installations dans IOStreams! Les erreurs de saisie sont normales et les exceptions sont pour, ainsi, exceptionnelle des erreurs. À l'aide de la conversion à bool après avoir lu une valeur fonctionne plutôt bien.

    • "Les erreurs de saisie sont normales et les exceptions sont pour, ainsi, exceptionnelle des erreurs" - et donc I/O de l'échec est d'une exceptionnelle erreur ou pas en fonction de la langue de programmation dans? L'expression anglaise "exceptionnel erreur" signifient réellement quelque chose d'autre que "je suis un incohate désapprobation pour votre utilisation de flux de contrôle dans un but que je considère comme négligeable". Et ainsi de suite.
    • Il est certainement vrai que les différentes langues ont des opinions différentes sur ce qui vaut la peine de lever une exception, et ce qui ne l'est pas. Il n'est donc pas étrange qu'un énoncé comme il semble.
    • ma demande vraiment, c'est que "les exceptions sont exceptionnels, des erreurs et des circonstances" est purement définition circulaire, et ne pas fournir des orientations utiles pour les programmeurs. Ce qui est vraiment nécessaire est un beaucoup plus détaillée, l'évaluation des avantages et des inconvénients des exceptions, qui tbh vient avec l'expérience, plutôt que de la simple formation et est en grande partie (mais pas entièrement), stylistique. Je ne veux pas critiquer Dietmar pour ne pas régler la question ici, simplement pour insinuer que c'est simple à régler 😉 Un programmeur en C pourrait heureusement conseils programmeurs C++ pour utiliser nothrow nouveau, depuis l'échec d'allocation est "normal".
    • Je ne suis certainement pas la désapprobation de l'utilisation d'exceptions. Par exemple, les rapports à cours de mémoire est un bon exemple d'une erreur qui pourrait se produire, mais le fait rarement. D'autre part, lors de la lecture d'un texte d'entrée, il ya une bonne chance que l'entrée n'est pas formaté comme prévu, ce qui entraîne une erreur. Je trouve que le fait de traiter avec des erreurs attendues localement fonctionne mieux que l'utilisation d'exceptions. Le IOStreams sont construites de manière à le rendre facile pour tester les erreurs sans traiter les exceptions. J'ai même décrit comment les utiliser avec des exceptions, je suis juste de s'opposer à l'utilisation de ce.
    • Je n'ai jamais vraiment senti que la probabilité qu'une erreur se produise, a beaucoup à voir avec la façon dont vous gérer, sauf bien sûr si cela affecte la façon dont vous optimiser. Comme vous le dites, vous voulez traiter l'erreur localement ou vous n'avez pas. Qui ne dépend pas de savoir si cela se produit une fois une deuxième ou une fois par an, ça dépend de quel composant de votre programme est capable de récupérer. Donc, vous pourriez trouver que lors de l'analyse interactive d'entrée vous prendre une approche différente lors de l'analyse par exemple un fichier. Le dernier cas est moins susceptible d'être localement récupérables, de sorte que les exceptions sont plus utiles.
    • +1, même si, en raison d'un vécu Python programmeur doit être parfaitement en mesure d'évaluer les conseils sur l'exception de l'utilisation pour eux-mêmes. L'interlocuteur peut sans aucun doute beaucoup de pratique d'intercepter les exceptions dans des endroits différents, depuis Python produit assez d'eux 🙂
    • En regardant votre réponse à la question que je vous voir jouer l'avocat du diable. Ce n'est pas le bon endroit pour discuter de ce sujet, bien que (et nous nous installons ce sujet).

    InformationsquelleAutor Dietmar Kühl
  3. 1

    Ruisseaux, ne pas jeter des exceptions par défaut (il peut être configuré pour le faire).

    Le code habituel de lire un int est:

    int a;
if (std::cin >> a) {
    # OK
} else {
    # error
}

    Mais être sûr que vous savez ce >> ne fait ici. Plus précisément, les nouveaux arrivants au C++ sont parfois surpris de constater que ce n'est pas nécessairement lire une ligne entière. Donc, si vous voulez valider l'ensemble de la ligne de saisie, ou si vous voulez réessayer en cas d'échec alors vous avez besoin de plus de code.

    InformationsquelleAutor Steve Jessop