Pour avoir utilisé les 2 types de gestion d'erreur, je fais tout pour éviter les langages avec référence nulle qui obligent à vérifier tout le temps qu'on a bien un objet valide.
En tout cas pour une valeur nulle en C, tu ne dois pas gérer cela partout. Sinon c'est lourd et inutile. Il y a quelques principes à respecter pour faire de la gestion d'erreur efficace. En gros en faisant de la programmation par contrat.
Si la valeur nulle est légitime (paramètre optionnel par exemple, ou que la fonction sait traiter comme un cas particulier), tu n'as pas le choix et tu dois le vérifier. Mais ce n'est pas une erreur en tant que tel mais disons un comportement particulier car le pointeur nul est considéré ici comme une entrée valide par ta fonction.
Sinon, cela signifie qu'une allocation mémoire a échoué quelque part. Or pour moi si une allocation échoue, c'est celui qui fait l'allocation qui doit vérifier si ça a réussi ou pas avant d'envoyer le pointeur nul à toutes les fonctions qui suivent. Cela permet de ne vérifier la validité d'un pointeur qu'à un seul endroit et d'alléger le code des fonctions qui s'attendent à un pointeur valide en entrée.
Car de toute façon, un pointeur nul n'est pas la seule valeur d'un pointeur invalide. Par accident, ou volontairement, le développeur peut affecter une adresse bidon comme 0x42424242 ou il a libéré la mémoire via free() mais continue d'utiliser le pointeur comme si de rien n'était... Or tu n'as aucun moyen de détecter ces cas de figures, le pointeur nul est finalement un cas particulier d'un pointeur invalide et pourtant le seul qu'on sait identifier à coup sûr.
Donc la vérification d'un pointeur valide ne peut se faire normalement que par l'appelant de la fonction, la fonction apellée sauf cas spéciaux ne doit pas se préoccuper de la validité du pointeur, le fait qu'on appelle la fonction sous entend qu'il est valide. Car tu ne peux le garantir toi même.
[^] # Re: "Billion dollar mistake"
Posté par Renault (site web personnel) . En réponse au lien Odin: Go done right?. Évalué à 5.
En tout cas pour une valeur nulle en C, tu ne dois pas gérer cela partout. Sinon c'est lourd et inutile. Il y a quelques principes à respecter pour faire de la gestion d'erreur efficace. En gros en faisant de la programmation par contrat.
Si la valeur nulle est légitime (paramètre optionnel par exemple, ou que la fonction sait traiter comme un cas particulier), tu n'as pas le choix et tu dois le vérifier. Mais ce n'est pas une erreur en tant que tel mais disons un comportement particulier car le pointeur nul est considéré ici comme une entrée valide par ta fonction.
Sinon, cela signifie qu'une allocation mémoire a échoué quelque part. Or pour moi si une allocation échoue, c'est celui qui fait l'allocation qui doit vérifier si ça a réussi ou pas avant d'envoyer le pointeur nul à toutes les fonctions qui suivent. Cela permet de ne vérifier la validité d'un pointeur qu'à un seul endroit et d'alléger le code des fonctions qui s'attendent à un pointeur valide en entrée.
Car de toute façon, un pointeur nul n'est pas la seule valeur d'un pointeur invalide. Par accident, ou volontairement, le développeur peut affecter une adresse bidon comme 0x42424242 ou il a libéré la mémoire via free() mais continue d'utiliser le pointeur comme si de rien n'était... Or tu n'as aucun moyen de détecter ces cas de figures, le pointeur nul est finalement un cas particulier d'un pointeur invalide et pourtant le seul qu'on sait identifier à coup sûr.
Donc la vérification d'un pointeur valide ne peut se faire normalement que par l'appelant de la fonction, la fonction apellée sauf cas spéciaux ne doit pas se préoccuper de la validité du pointeur, le fait qu'on appelle la fonction sous entend qu'il est valide. Car tu ne peux le garantir toi même.