Folco (./21) :
./19 Merci bien. Ca fait chier quelque part, ça veut dire que l'informatique n'est pas une science exacte, et qu'il y a un côté humain qui rentre en ligne de compte. Merde, c'était trop beau...

Folco (./21) :
Le truc, c'est que pour faire bien, faut vérifier jusqu'au moindre affichage de texture, qui ne pourrait merder que si on arrachait à chaud la carte graphique. C'est chiant et inutile à faire, mais c'est pas bien de pas le faire.

Tu peux avoir des cas d'échec auxquels tu n'as pas pensé. Es-tu sûr et certain que ton affichage de texture ne peut jamais échouer ? Qu'est-ce-qui se passe par exemple si l'utilisateur fait des trucs funky pendant que ton appli tourne (genre changer de résolution, débrancher un écran à chaud, etc.) ?

Partir du principe qu'une fonction qui peut renvoyer un code d'erreur n'échouera jamais, c'est risqué, sauf si concrètement l'échec est sans conséquences (exemple : un échec de fclose() quand tu quittes le programme) ou que tu connais exactement l'implémentation de la fonction et que tu peux prouver que ça ne peut pas se produire dans ton cas d'utilisation.

En pratique on s'habitue vite à vérifier systématiquement tous les codes de retour. Et en plus de te prémunir contre les cas d'échec auxquels tu n'as pas pensé à la conception, ça permet aussi de mettre en évidence des bugs de manière anticipée.
Imagine : tu fais un malloc de n octets, avec n toujours suffisamment petit donc que tu considères que ça ne peut pas échouer (pas bien, mais bref). Si t'as un bug ailleurs qui fait que n est très grand, vérifier le code de retour de malloc() te préviendra qu'il y a un problème tout de suite, plutôt que de te retrouver avec une segmentation fault à retardement. Même dans le cas cité avant, un fclose() qui échoue, ça alerte sur le fait qu'il y a un truc pas net (cas réel : le handle passé en paramètre était pas le bon).

Après, ce n'est pas parce que tu vérifies toutes les erreurs que tu dois les gérer indépendamment et prévoir des palliatifs pour tout. À part si tu fais des trucs critiques, tu peux très bien te contenter d'avoir un gestionnaire d'erreur générique qui va fermer proprement l'appli si un truc qui n'est pas censé se produire se produit.