c'est bien beau tout ça
mais la solution au probleme c'est quoi??????
"Jean-Marc" a écrit dans le message de
41a9d2dc$0$5387$
> "YannX" a écrit dans le message de
> news:%
> > Bnjr,
> >
> > [HS = idée dérivée de ce fil ]
> > Y a-t-il une solution efficace pour fermer
> > automatiquement une application dérivée
> > (typiquement Excel ou Word), lancée
> > à partir de VB-IDE, qd on ferme l'interpretation du pgm !
> >
> > Evidement le programme utilisateur s'était planté........
> > Donc pour revenir a une situation propre....
>
> Hello,
>
> Le programme utilisateur ne **doit** PAS se planter. Si il rencontre
> une erreur, ce qui est possible, le programme doit dans tous les cas
> récupérer l'erreur proprement, et remonter les appels. Même une erreur
> non prévue doit être récupérée, faire l'objet d'un message adéquat,
> genre: Erreur inattendue (err N°: X) rencontrée dans le Module
> "Nom_du_module", Fonction "Nom_de_la_fonction".
>
> Si la nature de l'erreur est telle qu'elle nécessite un arrêt du
> programme, cet arrêt doit toujours se faire de manière contrôlée,
> justement pour gérer ce genre de cas. On prévoit alors une procédure
> dite "Disaster recovery" qui se charge de ce genre de choses.
>
> Ca suppose évidemment d'avoir fait les choses proprement, c'est à dire
> de garder quelque part en mémoire ou sur disque l'état des choses qu'on
> a lancé/ouvert/alloué pour permettre le cas échéant de retrouver ses
> petits et de faire le ménage le plus proprement possible. Ca ne résoud
> peut être pas tout (genre une panne hardware) mais ça évite quand même
> plein d'ennuis.
>
> Tout cela s'applique aussi bien pour un programme en cours de
> developpement, donc s'exécutant depuis l'IDE que pour un programme
> terminé, qui s'exécute tout seul, hors de l'IDE. Ceci expliquant
> pourquoi le code doit inclure même dans une phase très précoce tout ce
> qu'il faut pour la gestion propre (et si possible centralisée) des
> erreurs.
>
> --
> Jean-marc
> "There are only 10 kind of people
> those who understand binary and those who don't."
>
>
c'est bien beau tout ça
mais la solution au probleme c'est quoi??????
"Jean-Marc" <nospam_jean_marc_n2@yahoo.fr> a écrit dans le message de
41a9d2dc$0$5387$ba620e4c@news.skynet.be...
> "YannX" <ydx_nospam@yahoo.fr> a écrit dans le message de
> news:%23JuuYqU1EHA.2112@TK2MSFTNGP15.phx.gbl...
> > Bnjr,
> >
> > [HS = idée dérivée de ce fil ]
> > Y a-t-il une solution efficace pour fermer
> > automatiquement une application dérivée
> > (typiquement Excel ou Word), lancée
> > à partir de VB-IDE, qd on ferme l'interpretation du pgm !
> >
> > Evidement le programme utilisateur s'était planté........
> > Donc pour revenir a une situation propre....
>
> Hello,
>
> Le programme utilisateur ne **doit** PAS se planter. Si il rencontre
> une erreur, ce qui est possible, le programme doit dans tous les cas
> récupérer l'erreur proprement, et remonter les appels. Même une erreur
> non prévue doit être récupérée, faire l'objet d'un message adéquat,
> genre: Erreur inattendue (err N°: X) rencontrée dans le Module
> "Nom_du_module", Fonction "Nom_de_la_fonction".
>
> Si la nature de l'erreur est telle qu'elle nécessite un arrêt du
> programme, cet arrêt doit toujours se faire de manière contrôlée,
> justement pour gérer ce genre de cas. On prévoit alors une procédure
> dite "Disaster recovery" qui se charge de ce genre de choses.
>
> Ca suppose évidemment d'avoir fait les choses proprement, c'est à dire
> de garder quelque part en mémoire ou sur disque l'état des choses qu'on
> a lancé/ouvert/alloué pour permettre le cas échéant de retrouver ses
> petits et de faire le ménage le plus proprement possible. Ca ne résoud
> peut être pas tout (genre une panne hardware) mais ça évite quand même
> plein d'ennuis.
>
> Tout cela s'applique aussi bien pour un programme en cours de
> developpement, donc s'exécutant depuis l'IDE que pour un programme
> terminé, qui s'exécute tout seul, hors de l'IDE. Ceci expliquant
> pourquoi le code doit inclure même dans une phase très précoce tout ce
> qu'il faut pour la gestion propre (et si possible centralisée) des
> erreurs.
>
> --
> Jean-marc
> "There are only 10 kind of people
> those who understand binary and those who don't."
>
>
c'est bien beau tout ça
mais la solution au probleme c'est quoi??????
"Jean-Marc" a écrit dans le message de
41a9d2dc$0$5387$
> "YannX" a écrit dans le message de
> news:%
> > Bnjr,
> >
> > [HS = idée dérivée de ce fil ]
> > Y a-t-il une solution efficace pour fermer
> > automatiquement une application dérivée
> > (typiquement Excel ou Word), lancée
> > à partir de VB-IDE, qd on ferme l'interpretation du pgm !
> >
> > Evidement le programme utilisateur s'était planté........
> > Donc pour revenir a une situation propre....
>
> Hello,
>
> Le programme utilisateur ne **doit** PAS se planter. Si il rencontre
> une erreur, ce qui est possible, le programme doit dans tous les cas
> récupérer l'erreur proprement, et remonter les appels. Même une erreur
> non prévue doit être récupérée, faire l'objet d'un message adéquat,
> genre: Erreur inattendue (err N°: X) rencontrée dans le Module
> "Nom_du_module", Fonction "Nom_de_la_fonction".
>
> Si la nature de l'erreur est telle qu'elle nécessite un arrêt du
> programme, cet arrêt doit toujours se faire de manière contrôlée,
> justement pour gérer ce genre de cas. On prévoit alors une procédure
> dite "Disaster recovery" qui se charge de ce genre de choses.
>
> Ca suppose évidemment d'avoir fait les choses proprement, c'est à dire
> de garder quelque part en mémoire ou sur disque l'état des choses qu'on
> a lancé/ouvert/alloué pour permettre le cas échéant de retrouver ses
> petits et de faire le ménage le plus proprement possible. Ca ne résoud
> peut être pas tout (genre une panne hardware) mais ça évite quand même
> plein d'ennuis.
>
> Tout cela s'applique aussi bien pour un programme en cours de
> developpement, donc s'exécutant depuis l'IDE que pour un programme
> terminé, qui s'exécute tout seul, hors de l'IDE. Ceci expliquant
> pourquoi le code doit inclure même dans une phase très précoce tout ce
> qu'il faut pour la gestion propre (et si possible centralisée) des
> erreurs.
>
> --
> Jean-marc
> "There are only 10 kind of people
> those who understand binary and those who don't."
>
>
Merci pour le rappel,
mais de facon opérationnelle ?
(voir ci-dessous)
Y
"Jean-Marc" a écrit dans le message de
news:41a9d2dc$0$5387$
> "YannX" a écrit dans le message de
> news:%
> > Bnjr,
> >
> > [HS = idée dérivée de ce fil ]
> > Y a-t-il une solution efficace pour fermer
> > automatiquement une application dérivée
> > (typiquement Excel ou Word), lancée
> > à partir de VB-IDE, qd on ferme l'interpretation du pgm !
> >
> > Evidement le programme utilisateur s'était planté........
> > Donc pour revenir a une situation propre....
>
> Hello,
>
> Le programme utilisateur ne **doit** PAS se planter. Si il rencontre
..........Vrai, mais nous savons que c'est faux .... ;-)
> récupérer l'erreur proprement, et remonter les appels. Même une erreur
C++ propose depuis longtemps un mécanisme
try .......catch des exceptions typées !
Comment le faire en Basic
> Tout cela s'applique aussi bien pour un programme en cours de
> developpement, donc s'exécutant depuis l'IDE que pour un programme
> terminé, qui s'exécute tout seul, hors de l'IDE. .....
Mais quand je suis en train de tester, et de corriger
(sans réflechir, diraient les anciens de la comilation a cartes
perforées)
J'ai pas envie de perdre mon temps a verifier ma barre de taches..
Voila pourquoi, je ne sais pas, peut-etre qu'un simple
App_X.Quit
Set App_X = Nothing dans le Form_close principal
serait-il exécuté après plantage du programme dans l'IDE
lorsque je referme l'exécution ?
> pourquoi le code doit inclure même dans une phase très précoce tout ce
> qu'il faut pour la gestion propre (et si possible centralisée) des
erreurs.
Des préconisations pour le centraliser (plus que le MsgBox de rigueur...)
Y
Merci pour le rappel,
mais de facon opérationnelle ?
(voir ci-dessous)
Y
"Jean-Marc" <nospam_jean_marc_n2@yahoo.fr> a écrit dans le message de
news:41a9d2dc$0$5387$ba620e4c@news.skynet.be...
> "YannX" <ydx_nospam@yahoo.fr> a écrit dans le message de
> news:%23JuuYqU1EHA.2112@TK2MSFTNGP15.phx.gbl...
> > Bnjr,
> >
> > [HS = idée dérivée de ce fil ]
> > Y a-t-il une solution efficace pour fermer
> > automatiquement une application dérivée
> > (typiquement Excel ou Word), lancée
> > à partir de VB-IDE, qd on ferme l'interpretation du pgm !
> >
> > Evidement le programme utilisateur s'était planté........
> > Donc pour revenir a une situation propre....
>
> Hello,
>
> Le programme utilisateur ne **doit** PAS se planter. Si il rencontre
..........Vrai, mais nous savons que c'est faux .... ;-)
> récupérer l'erreur proprement, et remonter les appels. Même une erreur
C++ propose depuis longtemps un mécanisme
try .......catch des exceptions typées !
Comment le faire en Basic
> Tout cela s'applique aussi bien pour un programme en cours de
> developpement, donc s'exécutant depuis l'IDE que pour un programme
> terminé, qui s'exécute tout seul, hors de l'IDE. .....
Mais quand je suis en train de tester, et de corriger
(sans réflechir, diraient les anciens de la comilation a cartes
perforées)
J'ai pas envie de perdre mon temps a verifier ma barre de taches..
Voila pourquoi, je ne sais pas, peut-etre qu'un simple
App_X.Quit
Set App_X = Nothing dans le Form_close principal
serait-il exécuté après plantage du programme dans l'IDE
lorsque je referme l'exécution ?
> pourquoi le code doit inclure même dans une phase très précoce tout ce
> qu'il faut pour la gestion propre (et si possible centralisée) des
erreurs.
Des préconisations pour le centraliser (plus que le MsgBox de rigueur...)
Y
Merci pour le rappel,
mais de facon opérationnelle ?
(voir ci-dessous)
Y
"Jean-Marc" a écrit dans le message de
news:41a9d2dc$0$5387$
> "YannX" a écrit dans le message de
> news:%
> > Bnjr,
> >
> > [HS = idée dérivée de ce fil ]
> > Y a-t-il une solution efficace pour fermer
> > automatiquement une application dérivée
> > (typiquement Excel ou Word), lancée
> > à partir de VB-IDE, qd on ferme l'interpretation du pgm !
> >
> > Evidement le programme utilisateur s'était planté........
> > Donc pour revenir a une situation propre....
>
> Hello,
>
> Le programme utilisateur ne **doit** PAS se planter. Si il rencontre
..........Vrai, mais nous savons que c'est faux .... ;-)
> récupérer l'erreur proprement, et remonter les appels. Même une erreur
C++ propose depuis longtemps un mécanisme
try .......catch des exceptions typées !
Comment le faire en Basic
> Tout cela s'applique aussi bien pour un programme en cours de
> developpement, donc s'exécutant depuis l'IDE que pour un programme
> terminé, qui s'exécute tout seul, hors de l'IDE. .....
Mais quand je suis en train de tester, et de corriger
(sans réflechir, diraient les anciens de la comilation a cartes
perforées)
J'ai pas envie de perdre mon temps a verifier ma barre de taches..
Voila pourquoi, je ne sais pas, peut-etre qu'un simple
App_X.Quit
Set App_X = Nothing dans le Form_close principal
serait-il exécuté après plantage du programme dans l'IDE
lorsque je referme l'exécution ?
> pourquoi le code doit inclure même dans une phase très précoce tout ce
> qu'il faut pour la gestion propre (et si possible centralisée) des
erreurs.
Des préconisations pour le centraliser (plus que le MsgBox de rigueur...)
Y
Re,
il y a plein de façons de faire, ça dépend du code. En pratique:
- des On error Goto dans TOUTES les fonctions, procédures
- des variables globales uniquement dans les modules
- une gestion d'erreur qui ne laisse rien passer
Dans le cas présent, quelque chose comme ça:
Volontairement *****très***** simplifié, mais qui fonctionne:
Option Explicit
Const P_MODULE_NAME = "FORM1"
Private Sub Command1_Click()
Dim aa As Word.Application
Dim n As Integer
Dim s As String
On Error GoTo abnormal_end
Set aa = New Word.Application
aa.Documents.Open ("c:truc.doc")
'
' ici je fais un truc qui crashe l'IDE
'
n = n / 0
aa.Documents.Close
aa.Quit
Set aa = Nothing
normal_end:
MsgBox "stop ok"
Exit Sub
abnormal_end:
MsgBox "nous avons une erreur."
Select Case Err.Number
Case 1
' code pour cette erreur
Case 2
' code pour celle ci
Case Else
' DISASTER
' l'erreur est si grave qu'il faut quitter
' mais pas comme un goret
s = "Unexpected error in module " & P_MODULE_NAME & "." &
s = s & "in function Command1_click" & vbCrLf
s = s & "Error code: " & Err.Number & " (" & Err.Description &
")" & vbCrLf
aa.Documents.Close
aa.Quit
Set aa = Nothing
MsgBox s
MsgBox "Je quitte"
Unload Me
End Select
End Sub
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
"YannX" a écrit dans le message de
news:ugoG%
> Merci pour le rappel,
> mais de facon opérationnelle ?
>
> (voir ci-dessous)
> Y
> "Jean-Marc" a écrit dans le message de
> news:41a9d2dc$0$5387$
> > "YannX" a écrit dans le message de
> > news:%
> > > Bnjr,
> > >
> > > [HS = idée dérivée de ce fil ]
> > > Y a-t-il une solution efficace pour fermer
> > > automatiquement une application dérivée
> > > (typiquement Excel ou Word), lancée
> > > à partir de VB-IDE, qd on ferme l'interpretation du pgm !
> > >
> > > Evidement le programme utilisateur s'était planté........
> > > Donc pour revenir a une situation propre....
> >
> > Hello,
> >
> > Le programme utilisateur ne **doit** PAS se planter. Si il
> ..........Vrai, mais nous savons que c'est faux .... ;-)
>
> > récupérer l'erreur proprement, et remonter les appels. Même une
> C++ propose depuis longtemps un mécanisme
> try .......catch des exceptions typées !
> Comment le faire en Basic
>
> > Tout cela s'applique aussi bien pour un programme en cours
> > developpement, donc s'exécutant depuis l'IDE que pour un
> > terminé, qui s'exécute tout seul, hors de l'IDE. .....
> Mais quand je suis en train de tester, et de corriger
> (sans réflechir, diraient les anciens de la comilation a cartes
> perforées)
> J'ai pas envie de perdre mon temps a verifier ma barre de taches..
>
> Voila pourquoi, je ne sais pas, peut-etre qu'un simple
> App_X.Quit
> Set App_X = Nothing dans le Form_close principal
> serait-il exécuté après plantage du programme dans l'IDE
> lorsque je referme l'exécution ?
>
> > pourquoi le code doit inclure même dans une phase très précoce tout
> > qu'il faut pour la gestion propre (et si possible centralisée)
> erreurs.
>
> Des préconisations pour le centraliser (plus que le MsgBox de
?
>
> Y
>
>
Re,
il y a plein de façons de faire, ça dépend du code. En pratique:
- des On error Goto dans TOUTES les fonctions, procédures
- des variables globales uniquement dans les modules
- une gestion d'erreur qui ne laisse rien passer
Dans le cas présent, quelque chose comme ça:
Volontairement *****très***** simplifié, mais qui fonctionne:
Option Explicit
Const P_MODULE_NAME = "FORM1"
Private Sub Command1_Click()
Dim aa As Word.Application
Dim n As Integer
Dim s As String
On Error GoTo abnormal_end
Set aa = New Word.Application
aa.Documents.Open ("c:truc.doc")
'
' ici je fais un truc qui crashe l'IDE
'
n = n / 0
aa.Documents.Close
aa.Quit
Set aa = Nothing
normal_end:
MsgBox "stop ok"
Exit Sub
abnormal_end:
MsgBox "nous avons une erreur."
Select Case Err.Number
Case 1
' code pour cette erreur
Case 2
' code pour celle ci
Case Else
' DISASTER
' l'erreur est si grave qu'il faut quitter
' mais pas comme un goret
s = "Unexpected error in module " & P_MODULE_NAME & "." &
s = s & "in function Command1_click" & vbCrLf
s = s & "Error code: " & Err.Number & " (" & Err.Description &
")" & vbCrLf
aa.Documents.Close
aa.Quit
Set aa = Nothing
MsgBox s
MsgBox "Je quitte"
Unload Me
End Select
End Sub
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
"YannX" <ydx_nospam@yahoo.fr> a écrit dans le message de
news:ugoG%23cX1EHA.3376@TK2MSFTNGP12.phx.gbl...
> Merci pour le rappel,
> mais de facon opérationnelle ?
>
> (voir ci-dessous)
> Y
> "Jean-Marc" <nospam_jean_marc_n2@yahoo.fr> a écrit dans le message de
> news:41a9d2dc$0$5387$ba620e4c@news.skynet.be...
> > "YannX" <ydx_nospam@yahoo.fr> a écrit dans le message de
> > news:%23JuuYqU1EHA.2112@TK2MSFTNGP15.phx.gbl...
> > > Bnjr,
> > >
> > > [HS = idée dérivée de ce fil ]
> > > Y a-t-il une solution efficace pour fermer
> > > automatiquement une application dérivée
> > > (typiquement Excel ou Word), lancée
> > > à partir de VB-IDE, qd on ferme l'interpretation du pgm !
> > >
> > > Evidement le programme utilisateur s'était planté........
> > > Donc pour revenir a une situation propre....
> >
> > Hello,
> >
> > Le programme utilisateur ne **doit** PAS se planter. Si il
> ..........Vrai, mais nous savons que c'est faux .... ;-)
>
> > récupérer l'erreur proprement, et remonter les appels. Même une
> C++ propose depuis longtemps un mécanisme
> try .......catch des exceptions typées !
> Comment le faire en Basic
>
> > Tout cela s'applique aussi bien pour un programme en cours
> > developpement, donc s'exécutant depuis l'IDE que pour un
> > terminé, qui s'exécute tout seul, hors de l'IDE. .....
> Mais quand je suis en train de tester, et de corriger
> (sans réflechir, diraient les anciens de la comilation a cartes
> perforées)
> J'ai pas envie de perdre mon temps a verifier ma barre de taches..
>
> Voila pourquoi, je ne sais pas, peut-etre qu'un simple
> App_X.Quit
> Set App_X = Nothing dans le Form_close principal
> serait-il exécuté après plantage du programme dans l'IDE
> lorsque je referme l'exécution ?
>
> > pourquoi le code doit inclure même dans une phase très précoce tout
> > qu'il faut pour la gestion propre (et si possible centralisée)
> erreurs.
>
> Des préconisations pour le centraliser (plus que le MsgBox de
?
>
> Y
>
>
Re,
il y a plein de façons de faire, ça dépend du code. En pratique:
- des On error Goto dans TOUTES les fonctions, procédures
- des variables globales uniquement dans les modules
- une gestion d'erreur qui ne laisse rien passer
Dans le cas présent, quelque chose comme ça:
Volontairement *****très***** simplifié, mais qui fonctionne:
Option Explicit
Const P_MODULE_NAME = "FORM1"
Private Sub Command1_Click()
Dim aa As Word.Application
Dim n As Integer
Dim s As String
On Error GoTo abnormal_end
Set aa = New Word.Application
aa.Documents.Open ("c:truc.doc")
'
' ici je fais un truc qui crashe l'IDE
'
n = n / 0
aa.Documents.Close
aa.Quit
Set aa = Nothing
normal_end:
MsgBox "stop ok"
Exit Sub
abnormal_end:
MsgBox "nous avons une erreur."
Select Case Err.Number
Case 1
' code pour cette erreur
Case 2
' code pour celle ci
Case Else
' DISASTER
' l'erreur est si grave qu'il faut quitter
' mais pas comme un goret
s = "Unexpected error in module " & P_MODULE_NAME & "." &
s = s & "in function Command1_click" & vbCrLf
s = s & "Error code: " & Err.Number & " (" & Err.Description &
")" & vbCrLf
aa.Documents.Close
aa.Quit
Set aa = Nothing
MsgBox s
MsgBox "Je quitte"
Unload Me
End Select
End Sub
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
"YannX" a écrit dans le message de
news:ugoG%
> Merci pour le rappel,
> mais de facon opérationnelle ?
>
> (voir ci-dessous)
> Y
> "Jean-Marc" a écrit dans le message de
> news:41a9d2dc$0$5387$
> > "YannX" a écrit dans le message de
> > news:%
> > > Bnjr,
> > >
> > > [HS = idée dérivée de ce fil ]
> > > Y a-t-il une solution efficace pour fermer
> > > automatiquement une application dérivée
> > > (typiquement Excel ou Word), lancée
> > > à partir de VB-IDE, qd on ferme l'interpretation du pgm !
> > >
> > > Evidement le programme utilisateur s'était planté........
> > > Donc pour revenir a une situation propre....
> >
> > Hello,
> >
> > Le programme utilisateur ne **doit** PAS se planter. Si il
> ..........Vrai, mais nous savons que c'est faux .... ;-)
>
> > récupérer l'erreur proprement, et remonter les appels. Même une
> C++ propose depuis longtemps un mécanisme
> try .......catch des exceptions typées !
> Comment le faire en Basic
>
> > Tout cela s'applique aussi bien pour un programme en cours
> > developpement, donc s'exécutant depuis l'IDE que pour un
> > terminé, qui s'exécute tout seul, hors de l'IDE. .....
> Mais quand je suis en train de tester, et de corriger
> (sans réflechir, diraient les anciens de la comilation a cartes
> perforées)
> J'ai pas envie de perdre mon temps a verifier ma barre de taches..
>
> Voila pourquoi, je ne sais pas, peut-etre qu'un simple
> App_X.Quit
> Set App_X = Nothing dans le Form_close principal
> serait-il exécuté après plantage du programme dans l'IDE
> lorsque je referme l'exécution ?
>
> > pourquoi le code doit inclure même dans une phase très précoce tout
> > qu'il faut pour la gestion propre (et si possible centralisée)
> erreurs.
>
> Des préconisations pour le centraliser (plus que le MsgBox de
?
>
> Y
>
>