soit avec un message (messageBox, printf/cout) soit avec un code de retour donné.
Qui va demander une allocation mémoire… Oups. Qui va partir en deadlock… Oups.
Oui et non. Ça dépend de ton programme et de l’usage que tu souhaites faire de cette mémoire. Tu pourrais parfaitement attendre une quelques secondes avant de retenter… choisir un algo plus lent mais moins gourmand…
Tu es conscient que ca veut dire de faire un try catch (ou une ERRNOerie) avec un fallback utile autour de chaque appel de méthode qui peut faire une allocation mémoire ? Quand tu es au niveau lib C sur un filtre UNIX c'est trivial. Maintenant explique moi:
comment tu gères ca correctement sur un navigateur web.
en quoi le résultat est systématiquement mieux que le suicide pour l'utilisateur
en quoi ton soft est meilleur (il vient de prendre 200% de ligne de code avec des chemins d'exécution à la con à tester).
Comme d'hab il faut faire attention à ne pas généraliser. Mais plus tu vas dan les GUI, les applis haut niveau, et les trucs compliqués plus la gestion de ce type d'erreur perd de son intêret par rapport aux couts engendrés et à ce que ca apporte. Ca peut être beaucoup plus payant de prévoir des blocs fonctionnels autonomes qui se suicident et repartent tout seul quand quelque chose va mal. La cohérence est facile à tester et prise en compte dans le design et tu mets pas du code qui sert à rien partout.
[^] # Re: Malloc Linux
Posté par ckyl . En réponse au journal Où il est question de D3, des communes de France et des performances SVG des moteurs de rendu. Évalué à 4.
Qui va demander une allocation mémoire… Oups. Qui va partir en deadlock… Oups.
Tu es conscient que ca veut dire de faire un try catch (ou une ERRNOerie) avec un fallback utile autour de chaque appel de méthode qui peut faire une allocation mémoire ? Quand tu es au niveau lib C sur un filtre UNIX c'est trivial. Maintenant explique moi:
Comme d'hab il faut faire attention à ne pas généraliser. Mais plus tu vas dan les GUI, les applis haut niveau, et les trucs compliqués plus la gestion de ce type d'erreur perd de son intêret par rapport aux couts engendrés et à ce que ca apporte. Ca peut être beaucoup plus payant de prévoir des blocs fonctionnels autonomes qui se suicident et repartent tout seul quand quelque chose va mal. La cohérence est facile à tester et prise en compte dans le design et tu mets pas du code qui sert à rien partout.