Discussion :

[Chessmaster1966]

Les ordinateurs d'aujourd'hui sont tellement puissant qu'il serait dommage de se priver d'un gestionnaire d'erreur de type "try...cach".

Même si, admettons, dans une boucle il y a perte de temps cela restera quand même dérisoire. Il vaut mieux gérer les erreurs proprement avec "try...catch" plutôt que de rien faire ou de le faire sois-même avec des "if".

Si tu fais de ton programme un programme extrêmement rapide sans gérer les éventuelles erreurs et qu'il plante ton programme ne servira à rien !!!

Je suis pour l'usage du standard "try...catch" quand bien sûr cela est nécessaire ce n'est pas parce qu'on aime qu'il faut en abuser.

Toute chose doit être prise avec modération.

[Astraya]

Les ordinateurs d'aujourd'hui sont tellement puissant qu'il serait dommage de se priver d'un gestionnaire d'erreur de type "try...cach".

Sur un ordinateurs oui, sur d'autres supports ce n'est pas vrai. Un ordinateur est un machine qui absorbe très bien les demandes excessives de mémoire ou de temps processeur. Les autres supports non.

Si tu fais de ton programme un programme extrêmement rapide sans gérer les éventuelles erreurs et qu'il plante ton programme ne servira à rien !!!

C'est pourtant la solution adopter dans les jeux vidéos actuel car on veux que ça sois rapide et si jamais une erreur est considérer trop importante, on le fais crashé même si on peut régler le problème en perdant du temps. On peux très bien l'observer lorsque qu'un jeu actuel plante et demande d'envoyé un rapport d'erreur.

[Chessmaster1966]

C'est pourtant la solution adopter dans les jeux vidéos actuel car on veux que ça sois rapide et si jamais une erreur est considérer trop importante, on le fais crashé même si on peut régler le problème en perdant du temps. On peux très bien l'observer lorsque qu'un jeu actuel plante et demande d'envoyé un rapport d'erreur.

Sur ce point je ne suis pas vraiment d'accord !

Utiliser des jeux qui lorsqu'ils rencontre une erreur sérieuse le jeu s'arrêtte, il n'y a rien de plus énervant et au final le jeu sera délaissé, c'est aussi dans ce domaine - des jeux - qu'ils y a le plus de "patch" afin de corriger les bugs suite à de mauvaise gestion d'erreurs afin de gagner du temps d'exécution.

Bien sûr il ne faut abuser des gestionnaire d'erreurs car c'est un mécanisme supplémentaire qui peut effectivement ralentir une boucle. C'est pour cela que les erreurs doivent être résolues par le programmeur surtout les erreurs de logique qui sont les plus difficiles à repérer.

Il faut également ne jamais laisser de "warning" générés par le compilateur non résolus !!!

Prendre de bonnes habitudes de programmation telle être hyper concentré, lire et relire son code par sois-même et par quelqu'un d'autre de confiance, ne pas se presser même si le temps nous presse, faire des petites pauses c'est nécessaire car rester 8 heures d'affiler assis à tapoter sur son clavier et écrire des algorithme n'est pas une bonne chose et est la première source d'erreur.

Bref.

Utiliser des "try...catch" là où c'est vraiment nécessaire même dans une boucle car je doute que le code suivant pénalise les performance :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
try
{
     int r;
     for(int i=0; i < 10000000; i++)
       r = MonCalcul(i);
}
catch(...)
{
    cout << "Ooops !, ça bug !!!\n";
}

Le code précédent ne sera pas moins rapide que celui là (sans try...catch) :

Code :

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

1
2
3
4
 
int r;
for(int i=0; i < 10000000; i++)
   r = MonCalcul(i);

[Chessmaster1966]

J'ai fait un petit test qui illustre ce que j'ai précédement exposé.
C'est à dire qu'un bloc "try...catch" ne nuit pas aux performances lorsqu'il teste une boucle qui à chaque tour une fonction est appelée.

Par contre il y a une contre performance lorsque le gestionnaire d'erreurs est placé dans la fonction appelée.

Mon test c'est basé sur une boucle 'for' qui a tourné 100000000 de fois.

Dans le premier cas j'ai obtenu 688 milisecondes et dans le deuxième cas plus d'une seconde (1291 milisecondes).

Conclusion il faut éviter de placer des gestionnaires d'erreurs ou des structures conditionnelles dans une fonction appelée plusieurs fois de suite notamment dans une boucle sauf si vous avez une bonne raison de le faire.

[Dr Dédé]

<HS>Sauf sur console </HS>

Oh, mais ça arrive sur console aussi. Fallout 3...

[Astraya]

Utiliser des jeux qui lorsqu'ils rencontre une erreur sérieuse le jeu s'arrêtte, il n'y a rien de plus énervant et au final le jeu sera délaissé, c'est aussi dans ce domaine - des jeux - qu'ils y a le plus de "patch" afin de corriger les bugs suite à de mauvaise gestion d'erreurs afin de gagner du temps d'exécution.

C'est pour ça qu'il y a une 10ène de testeur à temps plein qui tape dans tout les murs, font des trucs complétement loufoque pour chercher les erreurs. La plus part des bugs ne proviennent pas d'une mauvaise gestion d'erreurs, comme dis dans un poste précédent, quand ça marche pas on le saute, on ne le corrige pas. Certains saut son critique car nuise à l'expérience de jeu. C'est ces saut la qu'on corrige en priorité. 90% des patchs corriges des bugs d'affichage, des bugs de quêtes, des mise au point du gameplay... Pourquoi dis-t-on que c'est difficile de développer un jeu? parce que le code dois être robuste et envisager des cas délirants sans utilisé d'exceptions partout.

Conclusion il faut éviter de placer des gestionnaires d'erreurs ou des structures conditionnelles dans une fonction appelée plusieurs fois de suite notamment dans une boucle sauf si vous avez une bonne raison de le faire.

Malheureusement, un jeu est déjà au minimum une boucle. Une pile d'appel monstrueuses, des for_each, des if, des threads, du réseau....
Quand ça ne marche pas on saute et on espère que ça revienne pas a la prochaine frame. Si ça reviens trop souvent, on cherche et on corrige.
Beaucoup de jeu commerciaux, sorte avec des bugs trouvé mais pas corrigée car il faut du temps, et un simple try...catch n'est pas envisageable.

[Klaim]

Oh, mais ça arrive sur console aussi. Fallout 3...

Joel ne sait peut être pas que les dernières consoles peuvent être connectées online. Mais il a tout de même raison : la première version du jeu ne doit pas avoir ce genre de problème tout simplement parceque si la console n'est jamais connectée, le jeu en CD (si c'est un cd) doit quand même marcher...

[Dr Dédé]

Joel ne sait peut être pas que les dernières consoles peuvent être connectées online. Mais il a tout de même raison : la première version du jeu ne doit pas avoir ce genre de problème tout simplement parceque si la console n'est jamais connectée, le jeu en CD (si c'est un cd) doit quand même marcher...

Je suis bien d'accord, mais dans les faits, il y a toujours eu et il y a encore des jeux pour console qui plantent à l'occasion (cela se manifeste par un arrêt complet du jeu, nécessitant un redémarrage de la console). Par exemple: http://forums.2kgames.com/forums/showthread.php?t=79986

[Klaim]

Que cela existe c'est un fait naturel. Là on parlait plutot de ce que l'on VEUT, c'est à dire, ne pas avoir d'erreur.

Les erreurs en questions lorsqu'elles arrivent n'ont pas demoyen potable d'être corrigé par un catch. Au mieu on peut en faire un log et l'envoyer au développeur...

Une fois que l'erreur est survenue pour le joueur, l'experience se fissure immédiatement.

[Dr Dédé]

Que cela existe c'est un fait naturel. Là on parlait plutot de ce que l'on VEUT, c'est à dire, ne pas avoir d'erreur.

Les erreurs en questions lorsqu'elles arrivent n'ont pas demoyen potable d'être corrigé par un catch. Au mieu on peut en faire un log et l'envoyer au développeur...

Une fois que l'erreur est survenue pour le joueur, l'experience se fissure immédiatement.

J'ai eu la chance de travailler sur une production AAA pour console, et je peux t'assurer que je n'ai pas vu le moindre try catch. Beaucoup beaucoup d'asserts, oui. Assez pour couvrir une vaste gamme d'erreurs. Mais si une erreur filtre à travers tout ça, et qu'elle n'est pas détectée par l'assurance-qualité... c'est le plantage chez l'utilisateur. La seule solution, c'est vraiment des asserts à tous les coins de rue et un gros budget d'assurance-qualité. Et comme les plantages sur console sont somme toute rares, quoiqu'ils existent, la technique se révèle efficace.

[Klaim]

Tout a fait.

Ca ne vas pas a l'encontre de ce qu'on disait, bien au contraire. C'est typiquement le genre de cas ou l'utilisation des exceptions a peu d'interet. Et c'est pas nouveau dans le monde de l'embarqué (pas les smartphone, les trucs bien hardcore niveau restrictions).