Parce que le jour où ça passe par là, ça fait généralement très mal.
Très mal ? Ça segfault un peu plus loin, c’est tout.
Tu as un problème inattendu, le programme crash de manière inattendue. La vache de catastrophe horrible.
Alors je suis d’accord que dans certains cas, l’application ne doit jamais avoir de comportement indéfini, et dans ce cas oui, vérifier les exceptions/codes d’erreur est vital.
Je sais pas vous, mais 90% du code que je fais n’a pas de telles contraintes, et un crash si le disque dur grille et que fopen renvoie NULL, c’est tout à fait acceptable. Par contre, le temps supplémentaire passé à coder les tests de vérification « est-ce que malloc a renvoyé NULL », eux, sont déjà bien moins acceptables (parce que mine de rien, une gestion aussi fine des erreurs, c’est assez chronophage).
[^] # Re: gestion des erreurs
Posté par Moonz . En réponse à la dépêche Retour d'expérience sur Go. Évalué à -3.
Très mal ? Ça segfault un peu plus loin, c’est tout.
Tu as un problème inattendu, le programme crash de manière inattendue. La vache de catastrophe horrible.
Alors je suis d’accord que dans certains cas, l’application ne doit jamais avoir de comportement indéfini, et dans ce cas oui, vérifier les exceptions/codes d’erreur est vital.
Je sais pas vous, mais 90% du code que je fais n’a pas de telles contraintes, et un crash si le disque dur grille et que
fopenrenvoieNULL, c’est tout à fait acceptable. Par contre, le temps supplémentaire passé à coder les tests de vérification « est-ce quemalloca renvoyéNULL», eux, sont déjà bien moins acceptables (parce que mine de rien, une gestion aussi fine des erreurs, c’est assez chronophage).