c++ - try - S'assurer que les exceptions sont toujours prises




try catch c++ example (5)

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?

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

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?


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


Non.

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

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.


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_; }
}

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

Cependant, je suis curieux de connaître la racine de la question. Si l'utilisateur doit toujours envelopper 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 telle 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 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.





try-catch