Gestion des erreurs.

@Jack.

J'ai remarqué que l'erreur suivante n'était pas reconnue avec la commande 'on_error'.

Il s'agit de 'List index out of bounds'.

Second type d'erreur:

'file_load' d'un objet List, avec un fichier inexistant provoque un plantage, et n'est pas non plus reconnu.

Citation :

Il s'agit de 'List index out of bounds'.

Peux-tu donner un exemple ? Est-ce qu'il s'agit d'un problème purement Panoramic ou est-ce lié à quelque chose avec KGF.dll ?

Je croix savoir ce que voulait dire Pedro Alvarez.

L’erreur List index out of bounds peut être déclenchée s’il manque (par exemple) un END_SUB à une SUB
Dans l’exemple suivant, j’ai omis intentionnellement l’instruction end_sub pour provoquer l’erreur.
Bien qu’il y ait erreur, l’instruction ON_ERROR_GOTO ne se déclenche pas !  Le programme se déroule comme si elle n’existe pas.

Code:

label err
on_error_goto err
test()
end
err:
message "!!!! erreur !!!!"
off_error_goto
end
sub test()
    messge "hello"
' end_sub

Maintenant, si on remet l’instuction end_sub à sa place, alors  ON_ERROR_GOTO fait bien son travail pour signaler l’erreur de la ligne 10 (messge au lieu de message).

Donc (comme l’a remarqué Pedro)  l’erreur List index out of bounds n’est pas reconnue par la commande ON_ERROR_GOTO.



@Klaus
Rassure-toi, rien à voir avec KGF.DLL

Merci, Papydall. Effectivement, ça me rassure. J'ai tendance à mettre mes routines en cause si je ne comprends pas un comportement, je tente de reproduire puis de corriger un bug éventuel. Cette fois, ce n'est pas pour moi - tant mieux.

Je pense que Panoramic fait un contrôle au tout début sur la cohérence de l’ensemble du code ( un FOR doit avoir un NEXT, un IF doit avoir un END_IF, une SUB doit avoir un END_SUB, etc.).
Si, à ce niveau il détecte une erreur, il la signale AVANT de procéder à l’exécution du programme.
De ce point de  vue, je pense qu'il ne s'agit pas d'un bug dû à la commande ON_ERROR_GOTO.

Tuas certainement raison, et seul Jack pourra y faire quelque chose...

Il y a une autre erreur qui n'est pas captée par ON_ERROR. Elle génère un plantage par "I/O-error 22": c'est l'ouverture en écriture d'un fichier qui est ouvert en écriture par un autre programme. Générez le code suivant en EXE et lancez-le: il affichera "réussi". Laissez le programme actif et lancez-lé une seconde fois: il n'affichera pas "échoué", mais plante avec une erreur.

Code:

label bad
on_error_goto bad
file_open_write 1,"test.txt"
off_error_goto
message "réussi"
end
bad:
off_error_goto
message "échoué"
end

Salut tout le monde
Salut Klaus

Personnellement, je vois la chose non pas comme un bug de PANORAMIC, mais comme une erreur de programmation très fréquente de la part de tous (ou presque tous) les panoramiciens.
D’ailleurs j’ai parlé de ce problème je ne sais plus où.

J’ai toujours appris (avec la poignée de langages que j’ai utilisés quand j’avais 30 ans de moins que maintenant) qu’il est nécessaire de fermer tout fichier ouvert par quelque chose comme OPEN après avoir effectué les traitements sur lui et ce, au plus tard avant la fin du programme.  

J’ai remarqué que panoramic n’exige pas une telle précaution et les choses peuvent se dérouler d’une façon incompréhensible.
Pour ma part, je ferme toujours les fichiers ouverts avant de terminer mon programme.
Je me rappelle que j’ai écrit sur ce Forum que c’est une règle d’or le fait de CLOSE un fichier après l’avoir OPEN.

L'erreur (dans le seconde exécution) est due au fait que le fichier est déjà ouvert et ne peut pas être réouvert une seconde fois.

Si dans l’exemple que tu as donné, tu ajoutes file_close 1 , il n’y aura plus d’erreur.

Code:

label bad
on_error_goto bad
file_open_write 1,"test.txt"
file_writeln 1,"Salut tout le monde"
file_close 1
off_error_goto
message "réussi"
end
bad:
off_error_goto
message "échoué"
end

Qu'en pense-tu Klaus?

Tu n'as pas saisi ce que je voulais pointer. Le problème, c'est quand on veut accéder un fichier qui est, à ce moment-là, ouvert (et verrouillé) par un autre programme, dont on n'a pas la maitrise. C'est pour ça que j'ai fait cette petite démo: générer l'exe du code que j'ai posté, lancer cet exe, et SANS l'arrêter, le lancer une seconde fois. On devrait pouvoir intercepter une erreur "fichier ouvert par un autre programme" ou similaire. Windows le fait bien, pour ses programmes - donc, l'information est disponible et accessible. Mais Panoramic ne traite pas ce cas et le plantage arrive.

Ce que je demande, c'est que le noyau de Panoramic intercepte cette erreur et déclenche une erreur interceptable dans le style Panoramic.

Pour être encore plus précis, j'ai constaté que la commande FILE_RENAME intercepte correctement le cas où le fichier est verrouillé par un autre programme, contrairement à FILE_OPEN_WRITE qui plante dans ce cas.

Pour montrer, j'ai codé les deux cas dans le petit programme ci-après. Il faut à nouveau le générer en excutable, puis le lancer 2 fois, l'une après l'autre, sans arrêter la première instance. Et tel que le code est posté, il affiche bien "échoué" au deuxième lancement.

Si par contre, on active la ligne 5 et on désactive la ligne 6, on obtient un plantage, ce qui n'est pas normal.

Voici le code:

Code:

label bad
dim test$
'
' Activer une des deux lignes 5 ou 6
' test$ = "provoquer une erreur"
test$ = "marche sans erreur"

if test$="marche sans erreur"
  if file_exists("test.txt")=1
    on_error_goto bad
    file_rename "test.txt","test.bak"
    file_delete "test.bak"
    file_open_write 1,"test.txt"
    off_error_goto
  else
    file_open_write 1,"test.txt"
  end_if
  message "réussi"
  end
end_if

if test$="provoquer une erreur"
  on_error_goto bad
  file_open_write 1,"test.txt"
  off_error_goto
  message "réussi"
  end
end_if

bad:
  off_error_goto
  message "échoué"
  end

Klaus, tu as certainement raison et je vois bien le problème car il y en a bien un!
Il me semble que le remède est tout à fait possible : un simple FILE_CLOSE quand on a terminé tous les traitements sur le fichier, évitera tant de dysfonctionnements.
Pourquoi s’en priver ?
Il est aussi possible que je n’ai pas tout saisi  

Jack, c’est à toi !

Mais non, Papydall ! C'est bien là, le problème ! Dans ma démo, j'ai pris le même programme Panoramic lancé deux fois, et qui plante ou pas, suivant l'option choisie. Mais le problème n'est pas là.

Imagine un fichier créé et gardé ouvert par un autre programme, qui travaille dessus. Ca peut être n'importe quelle application, pas forcément en Panoramic. Lorsque dans mon programme Panoramic tente de créer ce même fichier, je voudrais pouvoir intercepter une erreur Panoramic via ON_ERROR_GOTO. Or, il y a bien une erreur, mais elle n'est pas interceptable et elle plante le programme ! Brutal, non ?

Par contre, et ma petite démo le montre, si je tente de faire un RENAME de ce fichier, alors là, je reçois bien une erreur interceptable, et je peux réagir en conséquence. Eh bien, la commande FILE_OPEN_WRITE devrait faire de même, comme FILE_RENAME !

Vu sous cet angle, je ne peux que soutenir ta demande.

Jack, il y a du pain sur la planche !


 

Une autre erreur qui n'est pas interceptée par ON_ERROR_GOTO:

Code:

label bad : on_error_goto bad
file_open_write 1,"XC:\test.dat"
file_writeln 1,"abc"
file_close 1
end
bad:
message "erreur"
end

Le chemin invalide dans la ligne 2 devrait déclencher le ON_ERROR_GOTO au lieu de faire I/O-eror 123.