Discussion :

[NoIdea]

Bonjour à tous. Étant arrivé à un stade de mon projet (une GUI) ou je dois décider d'une politique de gestion d'erreurs, j'aimerais votre avis. Ce projet utilise la SFML (qui ne lance aucune exception) et la STL (qui lance beaucoup d'exception). Ce projet est une librairie, la question ne concerne donc pas "les exceptions dans mon projet" mais "les exceptions pour les utilisateurs du projet".

Les questions :

-Quel impact à la gestion des exceptions sur les performances ?
-Peut-on se débrouiller pour que la STL ne lance jamais d'exception (comme pour la version de new qui renvoie en pointeur NULL en cas d'échec) ?
-Que faire dans les constructeurs si je décide de ne pas utiliser les exceptions ?
-Utiliser des exceptions alors que la SFML n'en utilise pas, est-ce vraiment gênant ?
-Dans le cas ou je n'utilise pas d'exceptions, où mettre les messages d'erreurs ?
-Dans le cas où j'utilise les exceptions, est-ce un avantage de utiliser les classes d'exceptions de la STL ?
-Que me conseiller vous (politique de gestion d'erreurs à la C ou avec exception)?

Merci à tous.

[Polo_asm]

Bonjour.
j'ai pas le temps de te répondre dans les détails, mais si tu enlève complétement les exceptions (option de compilation dans Visual C++) tu gagne en performances, sur un exécutable de 0,5Mo j'avais gagné 4% de vitesse, et 15% de taille de l'exécutable, mais ce n'est pas tout le temps pareil.
Si tu désactive la gestion des exceptions dans ton programme tu risque d'avoir quelques problèmes pour gérer les erreurs provenant de la STL.

dans ton code source tu peut faire quasiment sans les exceptions, par exemple la valeur de retour des fonction renvoie le code d'erreur si il y en a une. et tu fais tout les vérifications avec des conditions, c'est plus rapide niveau performances processeur, mais ton code sera peut être plus compliqué à lire. Comme en C quoi..

Si tu développe proprement tu devrais pouvoir t'en passer à la limite mais c'est un peu risqué.

[NoIdea]

dans ton code source tu peut faire quasiment sans les exceptions, par exemple la valeur de retour des fonction renvoie le code d'erreur si il y en a une. et tu fais tout les vérifications avec des conditions, c'est plus rapide niveau performances processeur, mais ton code sera peut être plus compliqué à lire. Comme en C quoi..

Oui, pas de problème la dessus, c'était plutôt comment demander à la STL de générer une valeur de retour au lieu d'une exception (surtout que dans les constructeurs...).

j'ai pas le temps de te répondre dans les détails, mais si tu enlève complétement les exceptions (option de compilation dans Visual C++) tu gagne en performances, sur un exécutable de 0,5Mo j'avais gagné 4% de vitesse, et 15% de taille de l'exécutable, mais ce n'est pas tout le temps pareil.

Ok merci, j'espère que gcc propose la même option...

[koala01]

Salut,

Bonjour à tous. Étant arrivé à un stade de mon projet (une GUI) ou je dois décider d'une politique de gestion d'erreurs, j'aimerais votre avis. Ce projet utilise la SFML (qui ne lance aucune exception) et la STL (qui lance beaucoup d'exception). Ce projet est une librairie, la question ne concerne donc pas "les exceptions dans mon projet" mais "les exceptions pour les utilisateurs du projet".

Les questions :

-Quel impact à la gestion des exceptions sur les performances ?

Normalement, il y a très peux de différence en terme de performance.

Les exceptions sont, généralement, gérées sur le modèle SJLJ (Set Jump, Long Jump). L'idée générale étant de remonter la pile d'appel jusqu'à ce que l'on se trouve en position de gérer l'exception

Si tu place un code de récupération de l'exception et qu'elle n'est jamais lancée, tu obtiens simplement une partie de code qui ne sera pas exécutée

-Peut-on se débrouiller pour que la STL ne lance jamais d'exception (comme pour la version de new qui renvoie en pointeur NULL en cas d'échec) ?

Certaines implémentations le permettent, avec les options de compilation "qui vont bien"... Mais pas toutes

-Que faire dans les constructeurs si je décide de ne pas utiliser les exceptions ?

créer ton propre allocateur ?

Ce n'est, normalement, pas tant un problème au niveau du constructeur (qui, rappelons le, est la seule fonction ne renvoyant rien), qu'un problème au niveau de new / new[]...

Tu peux parfaitement envisager de surcharger cet opérateur (ces opérateurs) de manière à ce qu'ils renvoient NULL si une exception a été lancée

Mais bon, cela impliquera malgré tout que tu devra vérifier chaque fois que l'allocation a réussi (en vérifiant que le pointeur renvoyé par new ne soit pas nul).

-Utiliser des exceptions alors que la SFML n'en utilise pas, est-ce vraiment gênant ?

Pas outre mesure.

Si une exception est lancée par une fonction qui est appelée par SFML, elle remontra la pile d'appel jusqu'à sortir de SFML. Tu pourra toujours la récupérer à ce moment là

-Dans le cas ou je n'utilise pas d'exceptions, où mettre les messages d'erreurs ?

La seule solution sera sans doute une variable globale, ou assimilée, avec tous les problèmes que cela peut impliquer

-Dans le cas où j'utilise les exceptions, est-ce un avantage de utiliser les classes d'exceptions de la STL ?

Cela peut en être un dans le sens où tu peux alors faire dériver tes exceptions personnalisées des exceptions de la SL.

Si tu veux simplement récupérer l'exception "de base", tu peux alors faire un catch(std :: excepion &e ) qui les récupérera d'office toutes

-Que me conseiller vous (politique de gestion d'erreurs à la C ou avec exception)?

Les exceptions permettent généralement l'obtention d'un code plus simple.

Il est très (trop ) facile de ne pas prendre en compte le retour de fonction, ou d'oublier un code d'erreur précis, et toute ta logique peut en souffrir.

Avec la gestion d'exception, tu n'a quasiment plus à t'inquiéter de cela: elle remontera la pile d'appel, et il n'y a que quand tu sais être en mesure d'apporter une (partie de la) solution que tu dois t'inquiéter de savoir si une exception a été lancée ou non

Ceci dit, il y a parfois quelques cas dans lesquels le retour d'erreur est une solution malgré tout acceptable, et il n'est même pas exclu d'envisager de mélanger les deux

Merci à tous.

De rien

[NoIdea]

Cette réponse, très complète amène d'autres questions :

-Quand une exception doit-elle être lancée ?
-----Quand le programme segfaultera si elle n'est pas traitée ?
-----Si il s'agit d'un problème inhabituel même si il n'y aura pas de problème majeur (le chargement d'une image à échoué => image valide mais blanche).
-Faut-il vérifié la validité des arguments passés en paramètre (si la fonction spécifie : "il ne faut pas passer NULL", faut-il faire un if(NULL) throw ?)

Cela peut en être un dans le sens où tu peux alors faire dériver tes exceptions personnalisées des exceptions de la SL.

Si tu veux simplement récupérer l'exception "de base", tu peux alors faire un catch(std :: excepion &e ) qui les récupérera d'office toutes

Cette réponse me parait un peu ambiguë car je parle des utilisateurs : préfèreront-ils n'avoir a traiter que le type d'exception de base de la STL ou préfèreront-ils que je crée mon propre type ?

Ceci dit, il y a parfois quelques cas dans lesquels le retour d'erreur est une solution malgré tout acceptable, et il n'est même pas exclu d'envisager de mélanger les deux

Dans ce cas, dans quel cas utiliser l'un, dans quel cas utiliser l'autre ?

[koala01]

Cette réponse, très complète amène d'autres questions :

-Quand une exception doit-elle être lancée ?
-----Quand le programme segfaultera si elle n'est pas traitée ?
-----Si il s'agit d'un problème inhabituel même si il n'y aura pas de problème majeur (le chargement d'une image à échoué => image valide mais blanche).

Deux écoles s'affrontent sur ce terrain:

La première estime qu'une exception ne doit être lancée que lors de la survenue d'un événement... exceptionnel.

L'autre estime que c'est une manière assez facile de faire remonter les erreurs jusqu'au point où il sera possible d'y apporter une solution.

-Faut-il vérifié la validité des arguments passés en paramètre (si la fonction spécifie : "il ne faut pas passer NULL", faut-il faire un if(NULL) throw ?)

Une exception est, au minimum, lancée lorsque tu constate que le système est dans un état incohérent, ou que la suite des opérations risque de placer le système dans un état incohérent.

Si tu as une fonction qui doit renvoyer une référence basée sur un pointeur qui peut être nul, par exemple, tu ne peux décemment pas envisager de renvoyer une référence sur quelque chose... d'inexistant.

Mais, comme tu n'as aucune possibilité de signaler que la référence est invalide, tu n'aura sans doute pas d'autre choix que de... lancer une exception.

Pour ce qui est du passage d'un pointeur en argument, j'utiliserais peut être plutôt une assertion, mais, si tu estimes effectivement que le fait de passer un pointeur nul placera le système dans un état incohérent (comprenons nous: ca peut ne placer qu'un objet dans un état incohérent ) tu peux parfaitement envisager de lancer une exception.

Cependant, il faut avouer que, idéalement, tu devrais surtout faire en sorte que la logique suivie lors du passage du pointeur comme argument s'assure de ne pas passer de pointeur nul

Cette réponse me parait un peu ambiguë car je parle des utilisateurs : préfèreront-ils n'avoir a traiter que le type d'exception de base de la STL ou préfèreront-ils que je crée mon propre type ?

A la limite, tu t'en fous...

Si tu fais dériver certaines de tes exceptions de std::runtime_error, d'autres de std::logical_error et d'autres encore de std::invalid_argument, la manière dont l'utilisateur les utilisera n'aura strictement aucune importance de ton coté:

S'il décide de les gérer sur base de catch (std::exception & e), il aura peut être du mal à déterminer ce qui a pu réellement se passer, et, s'il décide de les gérer sur base de catch(MySpecialException &e), il sera effectivement en mesure d'apporter une solution cohérente au problème qui est survenu.

Quoi qu'il en soit, ce n'est pas de ton ressort, même si tu peux effectivement essayer de l'orienter vers une solution ou une autre en fonction de la situation

Dans ce cas, dans quel cas utiliser l'un, dans quel cas utiliser l'autre ?

Il est très difficile de donner une règle générale à cette question.

On pourrait cependant dire que le retour d'erreur peut être utiliser quand tu sais que tu dispose directement de la possibilité d'apporter la solution au problème s'il survient.

Si tu dois attendre de retourner dans la fonction qui a appelé la fonction qui a appelé la fonction dans laquelle le problème survient, les exceptions seront clairement plus efficaces et faciles à utiliser.

Il y a eu ici un débat sur le sujet il y a déjà quelques temps... Peut être devrais tu faire la recherche du sujet

[NoIdea]

La première estime qu'une exception ne doit être lancée que lors de la survenue d'un événement... exceptionnel.

L'autre estime que c'est une manière assez facile de faire remonter les erreurs jusqu'au point où il sera possible d'y apporter une solution.

Ce n'est pas exactement les 2 cas que j'ai cités, mais je suppose qu'on peut les considérés comme équivalent.

Pour ce qui est du passage d'un pointeur en argument, j'utiliserais peut être plutôt une assertion, mais, si tu estimes effectivement que le fait de passer un pointeur nul placera le système dans un état incohérent (comprenons nous: ca peut ne placer qu'un objet dans un état incohérent ) tu peux parfaitement envisager de lancer une exception.

Ce que je voulais dire concernait plutôt : "Dois-je considérer que l'utilisateur de la fonction respecte la documentation et donc ne pas faire de vérification de validité des arguments" ou "Ma fonction doit-elle vérifié que les arguments sont valides".

Il y a eu ici un débat sur le sujet il y a déjà quelques temps... Peut être devrais tu faire la recherche du sujet

J'avais fait une recherche en tapant "les exceptions" dans la recherche sur ce forum, j'ai regardé la première et une partie de la deuxième page sans résultat.

[Flob90]

-----Si il s'agit d'un problème inhabituel même si il n'y aura pas de problème majeur (le chargement d'une image à échoué => image valide mais blanche).
-Faut-il vérifié la validité des arguments passés en paramètre (si la fonction spécifie : "il ne faut pas passer NULL", faut-il faire un if(NULL) throw ?)

Personnelement je ferais comme pour la S(T)L, le non respect des pré-requis implique un comportement indéfini, sauf si tu juges utile de lancer une exception (je dirai pour les pré-requis qui peuvent être difficiles à vérifier).

Je n'ai pas de lien vers la conversation dont parle koala, mais il était notamment question des bibliothèque microsoft qui préfère l'utilisation de retour pour les erreures. (il me semble)

Personnelement, ce que j'avais retenue d'interresent était la proposition d'utilisation simultané des deux méthodes, les exceptions dès que la fonction viole ses invariants et le retour pour le reste (en gros), ca me semble une bonne solution.

Une solution radicale si tu veus t'assurer que ta bibliothèque ne lancera pas d'exception est de toutes les "avaler", pour faire simple toutes tes fonctions contiennent un bloc try catch de la forme try{} catch(...){/*traitment générique*/} (et d'autre catch avant pour traiter des exceptions spécifiques), ainsi aucune exception ne peut être émise par ta bibliothèque. Je trouve ca assez sale mais ca doit marcher. (c'est une des technique possible pour s'assurer qu'un destructeur ne lance pas d'exception par exemple).

[koala01]

Ce que je voulais dire concernait plutôt : "Dois-je considérer que l'utilisateur de la fonction respecte la documentation et donc ne pas faire de vérification de validité des arguments" ou "Ma fonction doit-elle vérifié que les arguments sont valides".

Je vais encore devoir faire une réponse de normand à cette question :aile:...

Il est prudent de se dire que, s'il y a une bêtise à faire, tu trouvera fatalement un utilisateur qui la fera.

Ce n'est, ni plus ni moins , qu'une mise en application de la loi Murphy

De plus, il faut de toutes manières toujours te poser la question de ce qui peut se passer si l'utilisateur "joue à l'imbécile", l'idéal étant toujours de repérer ce genre de cas le plus tôt possible.

Maintenant, il y a malgré tout des cas où tu peux effectivement "zapper" la vérification.

Tu dois donc, pour chaque situation, évaluer le risque d'obtenir un argument incohérent et les conséquences qu'il pourra impliquer.

J'avais fait une recherche en tapant "les exceptions" dans la recherche sur ce forum, j'ai regardé la première et une partie de la deuxième page sans résultat.

Je crois que le titre du débat était de l'ordre "retour d'erreur ou exception", mais sans certitude

Il faut dire qu'en ayant participé à plus de 3000 discussions différentes, j'ai un peu de mal à en trouver une en particulier, surtout qu'elle n'est pas vraiment récente

[3DArchi]

Ce que je voulais dire concernait plutôt : "Dois-je considérer que l'utilisateur de la fonction respecte la documentation et donc ne pas faire de vérification de validité des arguments" ou "Ma fonction doit-elle vérifié que les arguments sont valides".

Pareil que Flob. Si ton utilisateur ne respecte pas le contrat de ta fonction, ta fonction n'est pas tenue de respecter sa part du contrat non plus. Donc les tests de cohérences sont inutiles car celles ci font parties du contrat de ta classe. (cf Programmation par contrat, application en C++ par Julien Blanc).

[Astraya]

Si ton utilisateur ne respecte pas le contrat de ta fonction, ta fonction n'est pas tenue de respecter sa part du contrat non plus.

Effectivement.

Si il s'agit d'un GUI pour une application 3D, l'utilisation des exceptions est très très déconseillé car cela plombe les performances dans le monde de la 3D. La solutions si jamais c'est le cas, si c'est critique niveau temps et ressources, c'est de faire la compilation pour des conditions qui ne sont pas respectés et qui sont évaluable à la compilation. pour cela il y a beaucoup de façon de faire, static_assert, static_if_else et autres trics.

[Aleph69]

Bonsoir,

désolé je vais donner une réponse très vague mais je suis sûr que les personnes de ce forum vont pouvoir compléter sans problème.
Il y a un passage dans le bouquin d'Alexandrescu qui explique comment vérifier si certaines conditions sont vérifiées à la compilation plutôt qu'à l'exécution. Ca doit s'appeler compile_check ou quelque chose dans le genre. Il passe par une macro. Ca pourrait peut-être te convenir dans certains cas.

[minnesota]

Je crois que le titre du débat était de l'ordre "retour d'erreur ou exception", mais sans certitude

salut,

Tu penses peut être au sujet « à propos de "l'idiome GetLastError" »

[koala01]

salut,

Tu penses peut être au sujet « à propos de "l'idiome GetLastError" »

Ce n'était pas forcément à ce débat là que je pensais (il me semble qu'il y en a un autre ), mais il résume malgré tout assez bien les différents aspects

[NoIdea]

Si ton utilisateur ne respecte pas le contrat de ta fonction, ta fonction n'est pas tenue de respecter sa part du contrat non plus.

Ok, c'est bien ce qu'il me semblait.

Il y a un passage dans le bouquin d'Alexandrescu qui explique comment vérifier si certaines conditions sont vérifiées à la compilation plutôt qu'à l'exécution. Ca doit s'appeler compile_check ou quelque chose dans le genre. Il passe par une macro. Ca pourrait peut-être te convenir dans certains cas.

J'ai tendance à penser que ce genre de chose utilise macro/template... et a donc tendance a nuire grandement à la lisibilité du code. Faut-il l'utiliser au détriment de la lisibilité ?

à propos de "l'idiome GetLastError"

J'ai lut le sujet en diagonal, et il me semble avoir noté que : "traité les exceptions localement nuit grandement aux performances comparé a un if"

Je me trompe ?

Si il s'agit d'un GUI pour une application 3D, l'utilisation des exceptions est très très déconseillé car cela plombe les performances dans le monde de la 3D.

Il s'agit d'un GUI pouvant être utilisé pour une application 3D. Dans quels cas une exceptions est-elle plus/aussi rentable (niveau performance) que des if ?
Dans quels cas une exception coute un temps complètement excessif ?
Dois-je vérifier les erreurs comme des new qui échouent (les problèmes de mémoire pouvant se poser mais plutôt rare) ?

[JolyLoic]

J'ai tendance à penser que ce genre de chose utilise macro/template... et a donc tendance a nuire grandement à la lisibilité du code. Faut-il l'utiliser au détriment de la lisibilité ?

La lisibilité n'est que modérément affectée dans le code client. De plus, dans la prochaine version du C++, ça fera partie des choses gérées nativement par le langage. Le problème est plutôt que c'est statique, c'est à dire que par exemple, quand il y a beaucoup de choses statiques à vérifier (quand on fait de la métaprogrammation, ou pour valider des aspects liés à la plateforme dans une programme portable...), c'est précieux, mais quand il y en a peu (un programme plus classique), ça sert moins souvent.

Il s'agit d'un GUI pouvant être utilisé pour une application 3D. Dans quels cas une exceptions est-elle plus/aussi rentable (niveau performance) que des if ?

Il y a deux aspects à considérer : Le coût de la gestion d'erreur quand aucune erreur n'est lancée, et son coût quand une erreur est lancée.

Sur le second aspect, une exception est assez lourde. Plus que des ifs.

Sur le premier, bien implémentée, un exception a un coût nul quand elle n'est pas lancée. Elle ne coûte donc dans ces cas là que le if permettant de savoir si on souhaite la lancer ou pas. Si l'on doit transmettre par code de retour une information d'erreur à travers 50 appels de fonction, il y aura par contre 50 if à faire (sachant qu'un if peut mettre en échec les algorithmes du processeur pour pré-calculer des choses).
Sans compter qu'écrire explicitement le code avec les ifs va facilement doubler la taille du code source, ce qui implique risque d'erreurs dans ce code, temps passer à l'écrire et le mettre au point, au détriment d'autres choses (optimisations)...

Dans quels cas une exception coute un temps complètement excessif ?

Si elle est lancée la moitié du temps, et qu'elle est attrapée directement dans la fonction au dessus.


J'ai lu l'affirmation que pour des IHM 3D, les exceptions étaient généralement déconseillées. Je mets fortement en doute cette affirmation. Déjà, qu'est-ce qui différencie ces applications d'autres applications qui ont des besoins de performance, et qui ferait que les exceptions seraient acceptables pour les autres, mais pas les applis d'IHM 3D ? Et ensuite, j'ai du mal avec un conseil booléen (exceptions/pas exception). Dans un tel logiciel, comme dans tout logiciel, il y a assurément des erreurs pour lesquelles une exception n'est pas le bon choix. Et d'autres où elles sont meilleures que les alternatives. Pour moi, la bonne granularité de choix pour exception/pas exception n'est pas la catégorie de logiciel, ni même le logiciel spécifique, mais l'erreur elle même.

[Astraya]

Dans quels cas une exceptions est-elle plus/aussi rentable (niveau performance) que des if ?

A ma connaissance jamais. Comme la dis koala, il s'agit de jump qui sont très chère lorsque tu cherches les millisecondes. Le bloc try catch est appelé à chaque frame, dans une boucle il ne faut pas oublié cela et un try catch dans une boucle c'est pas ce qu'on pourrais appelé de la performance.

Dans quels cas une exception coute un temps complètement excessif ?

Dans une boucle!

Dois-je vérifier les erreurs comme des new qui échouent (les problèmes de mémoire pouvant se poser mais plutôt rare) ?

Généralement (dans la 3D) les new "critiques" réserve une partie de la mémoire dans un bloc de taille préfixé, ils t'assurent de ne pas dépassé la mémoire que tu as besoin ce dont tu as besoin au minimum. Pour le reste, 90% c'est jugé assez critique pour faire planté l'application 3D.

[NoIdea]

La lisibilité n'est que modérément affectée dans le code client. De plus, dans la prochaine version du C++, ça fera partie des choses gérées nativement par le langage. Le problème est plutôt que c'est statique, c'est à dire que par exemple, quand il y a beaucoup de choses statiques à vérifier (quand on fait de la métaprogrammation, ou pour valider des aspects liés à la plateforme dans une programme portable...), c'est précieux, mais quand il y en a peu (un programme plus classique), ça sert moins souvent.

J'utilise déjà c++0x et toute ma gestion des évènements est faites grâce a variadique templates/lambda/tuples...
Cependant, je vois mal ce que je pourrais vérifié à la compilation (je suis obligé de passer par un void* pour les mettre dans un std::vector).
Je vais voir ce que je pourrais faire à la compilation mais j'ai des doutes...



Semblerait que vous ne soyez pas tout à fait d'accord sur les performances des exceptions...
Donc, si je comprend bien, malloc avec exception ne prend aucun temps a l'éxécution si je ne le catch qu'autour du main
(avec un code proche de )

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
int main()
{
try
{
//Code
}
catch(std::exception& e)
{
std::cout<<"erreur peu fréquente mais ne prend aucune performance ?";
}
}

Donc, je n'ai aucun intérêt (niveau performances) de changer l'allocateur par défaut de la std.

[Astraya]

Semblerait que vous ne soyez pas tout à fait d'accord sur les performances des exceptions

Et bien, comme partout, cela dépend du context de l'utilisation! La ou certaines choses peuvent être acceptées dans un domaine elles ne peuvent pas l'être dans d'autres et vice versa

[koala01]

A ma connaissance jamais. Comme la dis koala, il s'agit de jump qui sont très chère lorsque tu cherches les millisecondes. Le bloc try catch est appelé à chaque frame, dans une boucle il ne faut pas oublié cela et un try catch dans une boucle c'est pas ce qu'on pourrais appelé de la performance.

Je serais plutôt de l'avis de Loic sur ce coup là...

Si tu peux apporter une solution au problème au niveau de la fonction appelante (ou pire, au moment où le problème survient), un retour d'erreur est sans doute suffisant, mais si tu dois remonter la pile d'appels sur plusieurs fonctions avant de pouvoir apporter une réponse, l'exception sera largement préférable.

Le constat est en effet simple: tu dois tester le retour de la fonction partout alors que tu peux simplement ne pas placer de bloc try... catch si tu sais que, même si une erreur est survenue, tu ne peux de toutes façons rien y faire.

Un test if... else (ou switch) nécessite d'être évalué à chaque fois, qu'il y ait eu une erreur ou non, et tu sera obligé d'en placer dans toutes les fonctions, ne serait-ce que pour t'assurer que la fonction que tu appelle se déroule correctement

Si A appelle B qui appelle C qui apppelle D qui appelle E ... qui appellle Z, mais que la solution à un problème qui apparait dans Z ne se trouve que dans A, tu devra au minimum placer un test dans toutes les fonctions intermédiaires, et ce test prend malgré tout du temps.

Dans les mêmes circonstances, tu ne place ton bloc try catch que dans A, et, même si tu perd du temps à l'exécution (car cela revient à faire un test), tu ne perd qu'une fois le temps du test, au lieu de le perdre dans les 25 fonctions intermédiaires, et tu est sur de pouvoir récupérer le contexte exact dans lequel l'erreur s'est produite.

De toutes manières, il faut bien te dire que, si une erreur s'est produite "quelque part", il est malgré tout souvent plus intéressant de "perdre un peu de temps" à essayer de gérer l'erreur que de décider de laisser planter une application.

Un simple exemple: si tu laisse planter une application lorsque le chargement d'un fichier échoue, alors que tu as simplement oublié une lettre dans le nom du fichier que tu demande de charger, tu ne vas pas t'en sortir...

Quand on sait que le simple fait de provoquer l'affichage d'un message "j'ai pas trouvé le fichier" suffit pour éviter que l'application ne plante et pour permettre à l'utilisateur de corriger son erreur, il serait dommage de s'en priver, non, application 3D ou non

Dans une boucle!

Là, je suis d'accord...

Mais, si tu place ta boucle dans le bloc try (au lieu de placer le bloc try dans la boucle), tu t'arrête de toutes manières... à la première exception lancée, ce qui est généralement la meilleure manière de faire