Imaginons que Firefox et l'ensemble des plugin que tu utilisent soient tous exempte de bug. Ça n'empecherais pas de manger un sigkill par exemple. Le OOM peut faire la fête à ton logiciel sans qu'il n'y ai le moindre bug sur la machine. Et dans tout les cas, tu peut toujours avoir une panne de courant. C'est des cas qui arrivent dans la vraie vie et qui ne sont pas des bugs, qui ne sont pas liés à un langage ou un autre qui nécessitent d'être traité.
Hum, en fait, ici, il faut insérer une nuance, je panse (oh, ça rime huhu… ps: la faute est volontaire et.. gargantuesque)
Pour redevenir sérieux…
si un plugin mange un sigkill, gérer le sigkill de façon portable deviens juste… infernal.
Pourquoi? Parce que le sigkill, s'pas une exception, s'pas un bug du logiciel, mais, une demande de l'utilisateur. L'OS étant un utilisateur comme un autre, naturellement… faire la distinction est de mauvais goût, et amène à des bugs.
Qui est le dev pour aller contre l'OS, après tout? Ou de son utilisateur?
L'OOM dont tu parles, en revanche, c'est bel et bien une exception. Rarement gérée, mais exception tout de même, on peut s'en sortir si on la gère.
D'ailleurs, elle est liée à un bug, que ce soit de notre application, d'une autre, ou de l'OS. La gérer serait donc… élémentaire, si on veut un système parfait. Maintenant… a chaque allocation, supporter l'oom? C'est faisable, mais, combien de lignes de code pour une situation qui n'apparaitra jamais? Oh, allez, presque jamais… perso, j'en ai jamais vu qui ne soient pas dues à un autre bug… moui, une boucle infinie est "si vite arrivée"… par contre, les allocations trop grosses, ça… j'ai pas encore vu, mais je suis encore jeune, et j'ai pas eu la chance de bosser sur des systèmes à forte concurrence. Et pourtant… quand j'alloue, je vérifie le retour…
OOM => Out Of Memory => problème du système suite à une demande du logiciel.
SigKill => Signal Suicides-Toi! le système te demande de mourir, t'as pas ton mot à dire. Point final.
Si quelqu'un contredit ce dernier point, je le prie de citer une librairie qui fasse ce job, j'ai justement décidé de réécrire un soft libre avec un mécanisme de plug-in… j'ai déjà assez galéré pour que la 1ère fonctionnalité, le dessin, fonctionne, alors épargnez-moi de refaire la mécanique de plug-in 20 000 fois, merci. Je suis réellement preneur, vu que je n'ai aucun retour (bon, ok, logiciel en alpha, avec très peu de fonctions de bases, ça explique le manque de retours… mais c'est décourageant, j'ai envie de lâcher et de passer à un logiciel qui me serve plus… d'autant qu'opengl, c'est la croix et la bannière à comprendre!)
La différence est de taille… Sachant que, de façon classique, un plug-in est une bibliothèque, il est réellement complexe de dire, de façon portable, que si une bibliothèque doit mourir, l'appli en entier ne le doit pas.
A noter, tout de même, que ce problème est apparu avec les MDI (Multi Document Interface). Avant, il n'y aurait pas eu de souci puisque chaque logiciel n'aurait géré qu'une chose. On aurait donc tué qu'une seule chose.
La faute à qui? A l'utilisateur, pour le coup, qui refuse de comprendre que foutre un piston en l'air fout la machine entière en l'air, si c'est un PC. Dans le cas d'une voiture, c'est tout à fait différent, c'est tellement plus complexe, la mécanique… ben tiens!
Au passage, ne pas supporter l'exception OOM est un bug. Que toutes les applis ont, certes.
Mourir parce qu'on nous demande de mourir (sigkill) n'est pas un bug, mais une obéissance à l'OS.
D'ailleurs, on voit les processus qui bug: ils n'obéissent pas quand on les tue!!!
Pour l'article de boost, en très gros, il détaille plusieurs formes de résistances à l'exception, plus ou moins coûteuses en temps, en fonction des besoins.
Je ne me permettrait pas de le résumer, ce serait l'insulter, parce qu'il est déjà très compact et explicite… pour un programmeur orienté objet.
Mais, en très gros, il présent différents niveaux niveaux de support:
rien à foutre
j'envoie une exception si quelque chose se passe mal et je suis dans un état indéterminé.
j'envoie une exception si quelque chose merde, et je reste dans mon état précédent (rollback/commit)
Dans la pratique, récupérer d'une exception nécessite une bonne compréhension des chemins d'exécution. Ce dont peut de dev, je crois, peuvent se targuer, et surtout pas moi… c'est pour ça que quand je fais un programme, à la moindre situation ou j'ai un doute, je fais un test, et je balance une exception.
Le programmeur idéal ne pondrai que des fonctions de niveau 3, et donc on pourrait se permettre de les ignorer et les passer en simple avertissements. La réalité, c'est que si un fichier de config vital, il existe pas, ben on va pas l'inventer, sauf à être mono plateforme!
Ou alors, qu'on m'explique, ça m'intéresse pour autorealm, parce que toutes les exceptions que je lève jusque la, je vois pas comment les récupérer… d'ailleurs, mon souci, c'est juste d'avoir des crash qui disent pourquoi ça merde, parce que c'est déjà mieux que la moyenne…
La preuve, que ceux qui n'ont jamais eu d'application qui plante sans dire pourquoi lèvent la main! Et merde, j'y vois plus rien, baissez donc les bras… et puis d'ailleurs, pourquoi j'en lève 10, alors que j'en ai que deux?
[^] # Re: Plantages...
Posté par freem . En réponse à la dépêche Gnumeric 1.12. Évalué à -1.
Hum, en fait, ici, il faut insérer une nuance, je panse (oh, ça rime huhu… ps: la faute est volontaire et.. gargantuesque)
Pour redevenir sérieux…
si un plugin mange un sigkill, gérer le sigkill de façon portable deviens juste… infernal.
Pourquoi? Parce que le sigkill, s'pas une exception, s'pas un bug du logiciel, mais, une demande de l'utilisateur. L'OS étant un utilisateur comme un autre, naturellement… faire la distinction est de mauvais goût, et amène à des bugs.
Qui est le dev pour aller contre l'OS, après tout? Ou de son utilisateur?
L'OOM dont tu parles, en revanche, c'est bel et bien une exception. Rarement gérée, mais exception tout de même, on peut s'en sortir si on la gère.
D'ailleurs, elle est liée à un bug, que ce soit de notre application, d'une autre, ou de l'OS. La gérer serait donc… élémentaire, si on veut un système parfait. Maintenant… a chaque allocation, supporter l'oom? C'est faisable, mais, combien de lignes de code pour une situation qui n'apparaitra jamais? Oh, allez, presque jamais… perso, j'en ai jamais vu qui ne soient pas dues à un autre bug… moui, une boucle infinie est "si vite arrivée"… par contre, les allocations trop grosses, ça… j'ai pas encore vu, mais je suis encore jeune, et j'ai pas eu la chance de bosser sur des systèmes à forte concurrence. Et pourtant… quand j'alloue, je vérifie le retour…
Si quelqu'un contredit ce dernier point, je le prie de citer une librairie qui fasse ce job, j'ai justement décidé de réécrire un soft libre avec un mécanisme de plug-in… j'ai déjà assez galéré pour que la 1ère fonctionnalité, le dessin, fonctionne, alors épargnez-moi de refaire la mécanique de plug-in 20 000 fois, merci. Je suis réellement preneur, vu que je n'ai aucun retour (bon, ok, logiciel en alpha, avec très peu de fonctions de bases, ça explique le manque de retours… mais c'est décourageant, j'ai envie de lâcher et de passer à un logiciel qui me serve plus… d'autant qu'opengl, c'est la croix et la bannière à comprendre!)
La différence est de taille… Sachant que, de façon classique, un plug-in est une bibliothèque, il est réellement complexe de dire, de façon portable, que si une bibliothèque doit mourir, l'appli en entier ne le doit pas.
A noter, tout de même, que ce problème est apparu avec les MDI (Multi Document Interface). Avant, il n'y aurait pas eu de souci puisque chaque logiciel n'aurait géré qu'une chose. On aurait donc tué qu'une seule chose.
La faute à qui? A l'utilisateur, pour le coup, qui refuse de comprendre que foutre un piston en l'air fout la machine entière en l'air, si c'est un PC. Dans le cas d'une voiture, c'est tout à fait différent, c'est tellement plus complexe, la mécanique… ben tiens!
Au passage, ne pas supporter l'exception OOM est un bug. Que toutes les applis ont, certes.
Mourir parce qu'on nous demande de mourir (sigkill) n'est pas un bug, mais une obéissance à l'OS.
D'ailleurs, on voit les processus qui bug: ils n'obéissent pas quand on les tue!!!
Pour l'article de boost, en très gros, il détaille plusieurs formes de résistances à l'exception, plus ou moins coûteuses en temps, en fonction des besoins.
Je ne me permettrait pas de le résumer, ce serait l'insulter, parce qu'il est déjà très compact et explicite… pour un programmeur orienté objet.
Mais, en très gros, il présent différents niveaux niveaux de support:
Dans la pratique, récupérer d'une exception nécessite une bonne compréhension des chemins d'exécution. Ce dont peut de dev, je crois, peuvent se targuer, et surtout pas moi… c'est pour ça que quand je fais un programme, à la moindre situation ou j'ai un doute, je fais un test, et je balance une exception.
Le programmeur idéal ne pondrai que des fonctions de niveau 3, et donc on pourrait se permettre de les ignorer et les passer en simple avertissements. La réalité, c'est que si un fichier de config vital, il existe pas, ben on va pas l'inventer, sauf à être mono plateforme!
Ou alors, qu'on m'explique, ça m'intéresse pour autorealm, parce que toutes les exceptions que je lève jusque la, je vois pas comment les récupérer… d'ailleurs, mon souci, c'est juste d'avoir des crash qui disent pourquoi ça merde, parce que c'est déjà mieux que la moyenne…
La preuve, que ceux qui n'ont jamais eu d'application qui plante sans dire pourquoi lèvent la main! Et merde, j'y vois plus rien, baissez donc les bras… et puis d'ailleurs, pourquoi j'en lève 10, alors que j'en ai que deux?