S'assurer que les exceptions sont toujours?

Les exceptions en C ++ n'ont pas besoin d'être interceptées (pas d'erreurs de temps de compilation) par la fonction appelante. Il appartient donc au développeur de décider s'il doit les utiliser en utilisant try / catch (contrairement à Java).

Y a-t-il un moyen de s'assurer que les exceptions levées sont toujours interceptées en utilisant try / catch par la fonction appelante?

0
Le consensus sur l'approche procrustéenne de Java à l'égard des spécifications d'exception est que c'est gravement brisé.
ajouté l'auteur Pete Becker, source

7 Réponses

Non.

Voir Un regard pragmatique sur les spécifications d'exception pour des raisons différentes.

La seule façon de "l'aider" est de documenter les exceptions que votre fonction peut lancer, comme un commentaire dans le fichier d'en-tête le déclarant. Ceci n'est pas imposé par le compilateur ou quoi que ce soit. Utilisez les révisions de code à cette fin.

0
ajouté

En dehors de la portée de votre question, j'ai donc débattu de ne pas poster ceci mais en Java il y a en fait 2 types d'exceptions, cochées et non cochées. La différence fondamentale est que, comme dans c [++] , vous n'avez pas à attraper une exception non cochée.

Pour une bonne référence essayez ceci

0
ajouté

Ou vous pourriez commencer à lancer des exceptions critiques. Sûrement, une exception de violation d'accès interceptera l'attention de vos utilisateurs.

0
ajouté
Si vous aviez lu après la période, vous auriez pu remarquer que j'en ai explicitement mentionné un.
ajouté l'auteur Ryan Fox, source
Quoi, praytell, est une exception "critique"?
ajouté l'auteur John Dibling, source

Vous ne devriez pas utiliser une exception ici. Ce n'est évidemment pas un cas exceptionnel si vous avez besoin de l'attendre partout où vous utilisez cette fonction!

Une meilleure solution serait d'obtenir la fonction pour retourner une instance de quelque chose comme ça. Dans les versions de débogage (en supposant que les développeurs utilisent les chemins de code qu'ils viennent d'écrire), ils obtiendront une confirmation s'ils oublient de vérifier si l'opération a réussi ou non.

class SearchResult
{
  private:
    ResultType result_;
    bool succeeded_;
    bool succeessChecked_;

  public:
    SearchResult(Result& result, bool succeeded)
      : result_(result)
      , succeeded_(succeeded)
      , successChecked_(false)
    {
    }

    ~SearchResult()
    {
      ASSERT(successChecked_);
    }

    ResultType& Result() { return result_; }
    bool Succeeded() { successChecked_ = true; return succeeded_; }
}
0
ajouté
GCC a au moins un attribut de fonction pour exiger la gestion de la valeur de retour. Moins salissant que ce bool.
ajouté l'auteur Zan Lynx, source
@JohnDibling Montrez-moi quelqu'un qui est sérieux qui ne le dit pas.
ajouté l'auteur James Kanze, source
Il manque à cette classe un constructeur de copie et un opérateur d'affectation. Le constructeur de copie est très important, puisque les valeurs sont renvoyées par copie (qui peut être élidé). En C ++ 11, vous voulez probablement un constructeur de déplacement, plutôt qu'un constructeur de copie, puisque vous voulez réinitialiser successChecked dans l'objet en cours de copie.
ajouté l'auteur James Kanze, source
Montrez-moi un exemple de quelqu'un qui n'est pas un charlatan ou un hack en disant que les exceptions sont seulement pour les situations exceptionnelles.
ajouté l'auteur John Dibling, source
+1 à cela. Si vous attendez un résultat, il ne doit pas être renvoyé sous la forme d'une exception.
ajouté l'auteur macbirdie, source
@JohnDibling J'ai beaucoup entendu parler de développeurs Java, mais je n'ai pas encore entendu / vu ces mots exacts provenant de livres, de références ou de développeurs remarquables. Si c'est le cas, le (s) créateur (s) de Python n'a pas reçu le mémo :)
ajouté l'auteur Jason Mock, source

Il y a eu une tentative d'ajout de spécifications d'exception dynamique à la signature d'une fonction, mais depuis la langue ne pouvait pas faire respecter leur exactitude, ils ont ensuite été dépréciés.

En C ++ 11 et en avant, nous avons maintenant le spécificateur noexcept . > Encore une fois, si la signature est marquée pour lancer, il n'y a toujours pas de requriement qu'elle soit traitée par l'appelant.


Selon le contexte, vous pouvez vous assurer qu'un comportement exceptionnel est géré en le codant dans le système de types.

See: std::optional as part of the library fundamentals.

0
ajouté

Y a-t-il un moyen de s'assurer que le   exceptions levées sont toujours pris   en utilisant try / catch par l'appelant   fonction?

Je trouve ça plutôt drôle, que la foule Java - moi-même y compris - essaie d'éviter les exceptions vérifiées. Ils essaient de contourner le problème en étant obligés d'intercepter Exceptions en utilisant RuntimeExceptions .

0
ajouté

Chris' probably has the best pure answer to the question:

Cependant, je suis curieux de connaître la racine de la question. Si l'utilisateur doit toujours encapsuler l'appel dans un bloc try / catch, la fonction appelée par l'utilisateur devrait-elle réellement lancer des exceptions en premier lieu?

C'est une question difficile à répondre sans plus de contexte concernant la base de code en question. Tirant de la hanche, je pense que la meilleure réponse ici est d'enrouler la fonction de sorte que l'interface publique recommandée (si ce n'est pas seulement, en fonction du style global d'exception du code) fait l'essai / catch pour l'utilisateur Si vous essayez juste de vous assurer qu'il n'y a pas d'exceptions non gérées dans votre code, les tests unitaires et la révision de code sont probablement la meilleure solution.

0
ajouté