Shadow a écrit :Merci Olivier
L'exemple avec Point(x,y)
Point() est conçu pour ne pas vérifier où il pique sa couleur.
Résultats :
- 1) Dans le cas normal : il retourne la valeur du pixel
- 2) En cas de violation de domaine :
- 2a) En mode déboguage : Avertit et arrête le process
- 2b) En mode normal : (de manière non prévisible)
- 2b1) Soit il retourne une valeur chaotique
- 2b2) Soit il déguelingue l'intégrité mémoire (IMA) avec, comme effet non prévisible :
- 2b2a) subir un arrêt immédiat du process
- 2b2b) subir un arrêt ultérieur du process avec une IMA délocalisée de sa cause.
Conclusion : on peut simplement récupérer l'erreur que le compilateur fournit généreusement, ça c'est sûr. Mais ça s'arrête là, ça permet de rajouter des confettis et des petites fleurs au message d'erreur, voire de traduire l'erreur en 50 langues différentes, mais il n'existe pas de système possible qui puisse prendre en charge la qualité de l'erreur : ça ne sert qu'à renseigner le programmeur qui est "l'inventeur" de cette erreur.
Et en admettant que tu disposes d'un système magique, l'item 2b2 t'indique qu'en plus d'être magique dans l'instant, il faut que ton système soit devin pour déterminer à quel moment ton IMA va être fatale. Si l'IMA n'est pas immédiate, c'est une IMA
fausse, c'est-à-dire une
conséquence de ton erreur initiale. On ne doit plus seulement traiter d'un "point" anarchiste, mais d'une instruction "point" anarchiste
plus une instruction-surprise qui a son tour part en vrille.
Mais admettons que ton système magique soit aussi devin. Système qui, à raison de 10 lignes par instruction, au sein d'un jeu de 1000 instructions, te coûte directement 10 000 lignes de code, pour apporter une réponse qui permettra "seulement" de maintenir l'intégrité de ton programme. Si deux erreurs sont à traiter simultanément, parce que l'une a causé l'autre, parce que le débogueur n'est pas activé, et que tu fais la grève de la lucidité grâce à un système magique et devin, c'est 10 000 x 10 000 lignes de code, soit 100 millions de lignes de code qu'il te faut préparer.
Tu tapes une lignes en 10 secondes, ça fait un milliard de secondes pour programmer ton système.
Admettons que tu aies une machine à voyager dans le temps, pour que ton système soit prêt dans les délais, reste le problème du vieillissement pour programmer.
Admettons que tu sois immortel...
Je me permets de t'informer que, comme une majeure partie des instructions à arguments, nous disposons d'instructions qui renseignent des limites de ces arguments : pour l'exemple de Point(x,y), tu disposes de
(à compléter dans le code précédemment écrit, et qui rend le problématique item 2 impossible)
