Les types qui développent par exemple des outils de calcul dans la recherche vont peut-être avoir besoin d'allouer des Go, et captureront std::bad_alloc.
En mode "my life", c'est un peu ce qui m'arrive de faire, et je ne capture pas les exceptions. Évidemment, ça dépend du contexte (est-ce que c'est un soft largement distribué ou est-ce un code one-shot pour un projet en interne, etc), mais j'ai l'impression que le cas général dans la communauté scienifique, c'est qu'on cherche plus un comportement reproductible qu'une robustesse à toute épreuve. Si en fonction du contexte, ton soft utilise des bouts de code qui ne sont exécutés qu'en cas de bad_alloc, tu n'as aucune garantie que de refaire tourner ton calcul le lendemain après avoir pourri l'étudiant malotru qui osait avoir eu l'idée de faire un calcul sur le cluster en même temps que toi te donnera le même résultat.
En tout cas, à mon niveau et pour ce que je fais, le comportement souhaitable reste un abort() violent avec éventuellement un message d'erreur, que ce soit pour un problème d'allocation mémoire, d'accès disque en lecture/écriture, d'accès réseau, ou n'importe quel truc qui ne fonctionne pas exactement comme il le devrait. Tu rends la main, l'utilisateur résoud le problème, et relance le truc. D'ailleurs, de toutes manières, quand il y a des problèmes de mémoire et que tu fais partie des coupables, en général il y a plus de chances de se faire shooter par l'OOM killer que de lever toi-même une bad_alloc.
Ceci dit, je conçois tout à fait que ce n'est pas forcément non plus ce que tu souhaites si tu développes des logiciels utilisés par des milliers de chercheurs, ou sur des dispositifs embarqués, ou sur des appareils dont l'utilisation coûte des milliers d'euros à la minute, ou sur des trucs de calculs intensifs qui prennent 60 jours à tourner sur des clusters à 200 nœuds. C'est juste que pour beaucoup d'applications scientifiques, je pense qu'il est préférable d'éviter les comportements créatifs en cas de problème.
[^] # Re: Langages modernes
Posté par arnaudus . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 8.
En mode "my life", c'est un peu ce qui m'arrive de faire, et je ne capture pas les exceptions. Évidemment, ça dépend du contexte (est-ce que c'est un soft largement distribué ou est-ce un code one-shot pour un projet en interne, etc), mais j'ai l'impression que le cas général dans la communauté scienifique, c'est qu'on cherche plus un comportement reproductible qu'une robustesse à toute épreuve. Si en fonction du contexte, ton soft utilise des bouts de code qui ne sont exécutés qu'en cas de bad_alloc, tu n'as aucune garantie que de refaire tourner ton calcul le lendemain après avoir pourri l'étudiant malotru qui osait avoir eu l'idée de faire un calcul sur le cluster en même temps que toi te donnera le même résultat.
En tout cas, à mon niveau et pour ce que je fais, le comportement souhaitable reste un abort() violent avec éventuellement un message d'erreur, que ce soit pour un problème d'allocation mémoire, d'accès disque en lecture/écriture, d'accès réseau, ou n'importe quel truc qui ne fonctionne pas exactement comme il le devrait. Tu rends la main, l'utilisateur résoud le problème, et relance le truc. D'ailleurs, de toutes manières, quand il y a des problèmes de mémoire et que tu fais partie des coupables, en général il y a plus de chances de se faire shooter par l'OOM killer que de lever toi-même une bad_alloc.
Ceci dit, je conçois tout à fait que ce n'est pas forcément non plus ce que tu souhaites si tu développes des logiciels utilisés par des milliers de chercheurs, ou sur des dispositifs embarqués, ou sur des appareils dont l'utilisation coûte des milliers d'euros à la minute, ou sur des trucs de calculs intensifs qui prennent 60 jours à tourner sur des clusters à 200 nœuds. C'est juste que pour beaucoup d'applications scientifiques, je pense qu'il est préférable d'éviter les comportements créatifs en cas de problème.