Il faut identifier quelles valeurs seront nécessaires à la correction, où elles ont encore un sens, faire attention à leur durée de vie, ...
Des problèmes supplémentaires à résoudre, qui peuvent pousser à modifier l'architecture du programme pour la plier autour des erreurs. Faire de la "programmation orientée erreur".
C'est purement théorique. Faut arrêter d'avoir la tête dans le guidon et de faire des grandes affirmations sur les malheurs d'une solution tout ça parce qu'on ne l'aime pas ou la maitrise pas ou la connaît pas.
Quand tu écris une fonction, tu défini tes paramètres, ta (ou tes) sorties et la manière dont tu sort une erreur s'il est possible que tu plante. La réflexion est la même que tu envoie un code d'erreur, que tu utilise un bidule fonctionnel Option/Either ou que tu lève une exception. Rien de plus rien de moins. Si tu arrive à renvoyer une erreur via un code d'erreur tu devrait réussir à le faire avec une exception ne t'en fais pas trop ;)
La difficulté n'est pas dans le fait d'envoyer une erreur, mais dans la manière dont on la gère. Oui il peut paraître compliqué de gérer les exceptions (sans utiliser une solution moche comme beaucoup le font avec un traitement à tous les étages et un rethrow), mais tu as précisément la même problématique avec toutes les façons de gérer les erreurs. Oui il faut réfléchir à où c'est pertinent de récupérer ton erreur,. Oui ça peut donner l'impression de passer son temps à gérer des erreurs, mais un problème aussi complexe ne se gère pas en un coup de cuillère à pot.
Un point très pratique en C++, c'est que les exceptions normalisent tes erreurs. Si tu as une méthode qui retourne un entier et dont l'ensemble des entiers est une valeur acceptable, retourner une erreur va te demander soit d'enrober ton retour (avec un Optional par exemple) soit d'utiliser une variable globale (à la errno). Devoir jongler entre tester -1, 0, NULL, un objet encapsulant, ne rend pas pas les choses plus simples.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Je n'aime pas la SFML
Posté par barmic . En réponse à la dépêche SDL ou SFML ? Ne choisissez plus, prenez Gamedev Framework (gf). Évalué à 7.
C'est purement théorique. Faut arrêter d'avoir la tête dans le guidon et de faire des grandes affirmations sur les malheurs d'une solution tout ça parce qu'on ne l'aime pas ou la maitrise pas ou la connaît pas.
Quand tu écris une fonction, tu défini tes paramètres, ta (ou tes) sorties et la manière dont tu sort une erreur s'il est possible que tu plante. La réflexion est la même que tu envoie un code d'erreur, que tu utilise un bidule fonctionnel Option/Either ou que tu lève une exception. Rien de plus rien de moins. Si tu arrive à renvoyer une erreur via un code d'erreur tu devrait réussir à le faire avec une exception ne t'en fais pas trop ;)
La difficulté n'est pas dans le fait d'envoyer une erreur, mais dans la manière dont on la gère. Oui il peut paraître compliqué de gérer les exceptions (sans utiliser une solution moche comme beaucoup le font avec un traitement à tous les étages et un rethrow), mais tu as précisément la même problématique avec toutes les façons de gérer les erreurs. Oui il faut réfléchir à où c'est pertinent de récupérer ton erreur,. Oui ça peut donner l'impression de passer son temps à gérer des erreurs, mais un problème aussi complexe ne se gère pas en un coup de cuillère à pot.
Un point très pratique en C++, c'est que les exceptions normalisent tes erreurs. Si tu as une méthode qui retourne un entier et dont l'ensemble des entiers est une valeur acceptable, retourner une erreur va te demander soit d'enrober ton retour (avec un Optional par exemple) soit d'utiliser une variable globale (à la
errno). Devoir jongler entre tester -1, 0,NULL, un objet encapsulant, ne rend pas pas les choses plus simples.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)