Comme tu dit, les exceptions doivent être exceptionnelles. Ne pas trouver un élément dans une collection n’est pas exceptionel, c’est attendu, et ça doit absolument être géré au call site. Pour être tout à fait honnête, pour du code métier, c’est très dur de trouver un exemple ou les exceptions sont justifiées. Ton code métier, il a des cas d’erreurs, et ils sont spécifiés clairement (ou devraient l’être, à l’ingénieur de bosser avec ses stakeholder quand il en découvre). Les erreurs techniques, dans leur immense majorité, elles sont plutôt predictibles, et se ramènent très souvent à une erreur métier. Ta db est en carafe? Est ce que c’est si différent que ne pas trouver ton élément? Probablement pas.
Ton dao/repository/whathaveyou, lui va probablement vouloir faire la différence entre « pas trouvé » et « bestel il a pété la db et elle a fait pfft », pour ton logging/monitoring notamment. Mais la encore, y’a des façons beaucoup plus élégante de représenter ca. Tu reçoit soit le résultat, soit une erreur. Ça se modèle très bien avec un tuple, et des enums vont rendre le code de gestions d’erreur beaucoup plus simple à écrire parce que ca se découvre tout seul.
Je ne mettrais pas plus de disque dans un cas exceptionel non plus. Les I/O ça peut foirer pour un paquet de raisons tout à fait légitimes et courantes. Idem pour le réseau. C’est pas vraiment un cas exceptionel, et si le call site par du principe que l’io va passer, ben le code est très fondamentalement buggé (et a probablement des problèmes plus gros que de savoir s’il faut lancer une exception).
Plus de ram, je mettrais ça effectivement dans une exception. Essentiellement parce que si t’as plus de ram, c’est potentiellement très difficile de s’en sortir, vu que tu risques d’avoir besoin de ram pour libérer de la ram. Disons que c’est un peu la branche sur laquelle t’es assise, si elle pete, ça devient tout de suis plus compliqué.
Bref, de mon point de vue, les exceptions posent 2 gros problèmes:
- perte complète du flow de contrôle ou tu vas de la à de la d’un coup sans crier gare
- problèmes des performance lié au stack unwinding etc
Le deuxième point s’applique surtout à des très gros projets, donc rarement pertinent pour le commun des mortels. Ça se mitige bien si le compilateur transforme le type de retour pour un tuple (typeDeRetour, Erreur) de façon transparente, et ajoute le sucre syntaxique à la volée. Genre ce que fait swift. Bon courage pour introduire ça en c++ par contre, le train a quitté la gare, comme on dit outre quebin.
Le premier, ça devient plus compliqué. Déjà, les unchecked exceptions, c’est vraiment de la merde. Ça sort de nul part et paf, pastèque. Forcer à les déclarer aide. Forcer un try léger au call site aide aussi. Ça évite de faire un appel qui peut lancer, et le rater parce que ta signature inclue l’erreur lancée.
Alors, certes, ta fonction peut aussi lancer, et celle qui l’appelle aussi, sur 50 niveaux, retour à la case départ, on a un goto déguisé. Pour être tout à fait honnête, si tes exceptions bubblent sur plus de 2 niveaux, t’as un très très très gros problème de leaky abstraction. Les couches ne sont pas isolées du tout si tu peux remonter plus de 2 niveaux. Et ça, c’est un bien plus gros problème que de savoir si les exceptions sont autorisees ou pas.
ça nous laisse avec des cas réellement exceptionnels, qui se comptent sur les doigts d’une main. Genre « on a plus de ram » ou « un des core du cpu a disparu à la volée » et autres cas tarabiscotés du genre. J’ai pas de réponse pour ce cas là. Mais disons que c’est très très très loin d’être courant, et si ce genre de gestion représente plus de 0.00001% du code écrit, je serais surprit. Je serais déjà surprit si ne serait ce que 1% des projets gèrent ce genre de problèmes.
Bref, au final, c’est un faux débat. Le concept même de l’exception (une erreur opaque que tu rebalance au niveau supérieur) est plutôt un anti pattern, et se gère beaucoup mieux avec un type result, ou un tuple syntaxique. Et vu le pot de pus que sont les exceptions en c++, je trouve pas ça délirant de les interdire.
[^] # Re: Pas de fumée sans feu
Posté par groumly . En réponse au journal De l'influence néfaste de Google sur les développeurs C++. Évalué à 10.
Comme tu dit, les exceptions doivent être exceptionnelles. Ne pas trouver un élément dans une collection n’est pas exceptionel, c’est attendu, et ça doit absolument être géré au call site. Pour être tout à fait honnête, pour du code métier, c’est très dur de trouver un exemple ou les exceptions sont justifiées. Ton code métier, il a des cas d’erreurs, et ils sont spécifiés clairement (ou devraient l’être, à l’ingénieur de bosser avec ses stakeholder quand il en découvre). Les erreurs techniques, dans leur immense majorité, elles sont plutôt predictibles, et se ramènent très souvent à une erreur métier. Ta db est en carafe? Est ce que c’est si différent que ne pas trouver ton élément? Probablement pas.
Ton dao/repository/whathaveyou, lui va probablement vouloir faire la différence entre « pas trouvé » et « bestel il a pété la db et elle a fait pfft », pour ton logging/monitoring notamment. Mais la encore, y’a des façons beaucoup plus élégante de représenter ca. Tu reçoit soit le résultat, soit une erreur. Ça se modèle très bien avec un tuple, et des enums vont rendre le code de gestions d’erreur beaucoup plus simple à écrire parce que ca se découvre tout seul.
Je ne mettrais pas plus de disque dans un cas exceptionel non plus. Les I/O ça peut foirer pour un paquet de raisons tout à fait légitimes et courantes. Idem pour le réseau. C’est pas vraiment un cas exceptionel, et si le call site par du principe que l’io va passer, ben le code est très fondamentalement buggé (et a probablement des problèmes plus gros que de savoir s’il faut lancer une exception).
Plus de ram, je mettrais ça effectivement dans une exception. Essentiellement parce que si t’as plus de ram, c’est potentiellement très difficile de s’en sortir, vu que tu risques d’avoir besoin de ram pour libérer de la ram. Disons que c’est un peu la branche sur laquelle t’es assise, si elle pete, ça devient tout de suis plus compliqué.
Bref, de mon point de vue, les exceptions posent 2 gros problèmes:
- perte complète du flow de contrôle ou tu vas de la à de la d’un coup sans crier gare
- problèmes des performance lié au stack unwinding etc
Le deuxième point s’applique surtout à des très gros projets, donc rarement pertinent pour le commun des mortels. Ça se mitige bien si le compilateur transforme le type de retour pour un tuple (typeDeRetour, Erreur) de façon transparente, et ajoute le sucre syntaxique à la volée. Genre ce que fait swift. Bon courage pour introduire ça en c++ par contre, le train a quitté la gare, comme on dit outre quebin.
Le premier, ça devient plus compliqué. Déjà, les unchecked exceptions, c’est vraiment de la merde. Ça sort de nul part et paf, pastèque. Forcer à les déclarer aide. Forcer un try léger au call site aide aussi. Ça évite de faire un appel qui peut lancer, et le rater parce que ta signature inclue l’erreur lancée.
Alors, certes, ta fonction peut aussi lancer, et celle qui l’appelle aussi, sur 50 niveaux, retour à la case départ, on a un goto déguisé. Pour être tout à fait honnête, si tes exceptions bubblent sur plus de 2 niveaux, t’as un très très très gros problème de leaky abstraction. Les couches ne sont pas isolées du tout si tu peux remonter plus de 2 niveaux. Et ça, c’est un bien plus gros problème que de savoir si les exceptions sont autorisees ou pas.
ça nous laisse avec des cas réellement exceptionnels, qui se comptent sur les doigts d’une main. Genre « on a plus de ram » ou « un des core du cpu a disparu à la volée » et autres cas tarabiscotés du genre. J’ai pas de réponse pour ce cas là. Mais disons que c’est très très très loin d’être courant, et si ce genre de gestion représente plus de 0.00001% du code écrit, je serais surprit. Je serais déjà surprit si ne serait ce que 1% des projets gèrent ce genre de problèmes.
Bref, au final, c’est un faux débat. Le concept même de l’exception (une erreur opaque que tu rebalance au niveau supérieur) est plutôt un anti pattern, et se gère beaucoup mieux avec un type result, ou un tuple syntaxique. Et vu le pot de pus que sont les exceptions en c++, je trouve pas ça délirant de les interdire.