S'assurer que les exceptions sont toujours détectées

Question

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

Existe-t-il un moyen de garantir que les exceptions levées sont toujours interceptées à l'aide de try/catch par la fonction appelante ?

Answer 1

Non.

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

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

Answer 2

Vous ne devriez pas utiliser d'exception ici.Ce n'est évidemment pas un cas exceptionnel si vous devez vous y attendre partout où vous utilisez cette fonction !

Une meilleure solution serait que la fonction renvoie une instance de quelque chose comme ceci.Dans les versions de débogage (en supposant que les développeurs exercent les chemins de code qu'ils viennent d'écrire), ils obtiendront une assertion 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_; }
}

Answer 3

En dehors du cadre de votre question, j'ai donc débattu de ne pas publier ceci, mais en Java, il existe en fait 2 types d'exceptions, cochées et non cochées.La différence fondamentale est que, tout comme dans c[++], vous n'êtes pas obligé d'intercepter une exception non vérifiée.

Pour une bonne référence essaye ça

Answer 4

Chris' a probablement la meilleure réponse pure à la question :

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

C'est une question difficile à répondre sans plus de contexte concernant la base de code en question.En partant de la hanche, je pense que la meilleure réponse ici est de résumer la fonction de telle sorte que l'interface publique recommandée (sinon seulement, en fonction du style d'exception global du code) effectue le try/catch pour l'utilisateur.Si vous essayez simplement 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 du code sont probablement la meilleure solution.

Answer 5

Existe-t-il un moyen que l'on puisse s'assurer que les exceptions lancées sont toujours capturées à l'aide d'essayer / capter par la fonction d'appel?

Je trouve plutôt drôle que la foule Java... moi y compris - essaie d'éviter les exceptions vérifiées.Ils essaient de contourner le fait d'être obligés d'intercepter les exceptions en utilisant Exceptions d'exécution.

Answer 6

Il y a eu une fois une tentative d'ajouter spécifications d'exception dynamiques à la signature d'une fonction, mais comme le langage ne pouvait pas garantir leur exactitude, ils ont ensuite été dépréciés.

En C++11 et versions ultérieures, nous avons maintenant le spécificateur nosauf.
Encore une fois, si la signature est marquée pour être lancée, il n'est toujours pas nécessaire qu'elle soit traitée par l'appelant.

---

Selon le contexte, vous pouvez garantir que les comportements exceptionnels seront gérés en les codant dans le système de types.

Voir: std :: facultatif dans le cadre des principes fondamentaux de la bibliothèque.

Answer 7

Ou vous pourriez commencer à lancer des exceptions critiques.Il est certain qu'une exception de violation d'accès attraper l'attention de vos utilisateurs.