De ce que je sais, les exceptions ont été conçues pour faciliter la gestion des erreurs, quelles qu'elles soient. Je ne vois pas en quoi la nature de l'erreur change quoi que ce soit, d'autant plus lorsqu'elle est basée sur ces notions d'attendu/inattendu, pour autant qu'il y ai une définition précise et univoque des ces notions. En outre, la nature d'une même erreur peut varier selon le contexte. Reprenons l'exemple ci-dessus, en supposant que l'interface soit une interface Web. On peut envisager que, lors de la validation du formulaire, avant son envoi, un script JS soit exécuté pour vérifier si le champ est bien rempli, et n'envoyer le formulaire qu'à cette condition, ou, sinon, signaler à l'utilisateur qu'il lui faut remplir ce champ. Au niveau du code C++, le contenu du champ ne peut, théoriquement, jamais être vide, mais c'est une bonne pratique que de le vérifier tout de même, on ne sait jamais. Du coup, si cette erreur se produit tout de même (il peut y avoir un bug dans le code JS), erreur attendue ou inattendue ?
Zelbinium: pour la génération qui crée, pas celle qui scrolle...
[^] # Re: De l’utilité des exceptions.
Posté par Claude SIMON (site web personnel) . En réponse à la dépêche SDL ou SFML ? Ne choisissez plus, prenez Gamedev Framework (gf). Évalué à 1.
De ce que je sais, les exceptions ont été conçues pour faciliter la gestion des erreurs, quelles qu'elles soient. Je ne vois pas en quoi la nature de l'erreur change quoi que ce soit, d'autant plus lorsqu'elle est basée sur ces notions d'attendu/inattendu, pour autant qu'il y ai une définition précise et univoque des ces notions. En outre, la nature d'une même erreur peut varier selon le contexte. Reprenons l'exemple ci-dessus, en supposant que l'interface soit une interface Web. On peut envisager que, lors de la validation du formulaire, avant son envoi, un script JS soit exécuté pour vérifier si le champ est bien rempli, et n'envoyer le formulaire qu'à cette condition, ou, sinon, signaler à l'utilisateur qu'il lui faut remplir ce champ. Au niveau du code C++, le contenu du champ ne peut, théoriquement, jamais être vide, mais c'est une bonne pratique que de le vérifier tout de même, on ne sait jamais. Du coup, si cette erreur se produit tout de même (il peut y avoir un bug dans le code JS), erreur attendue ou inattendue ?
Zelbinium: pour la génération qui crée, pas celle qui scrolle...