Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
François Picalausa
On Sep 12, 10:22 am, "Giques" wrote:
Bonjour à tous,
J'ai un programme qui doit tourner en permanence sur un ordinateur, ce programme sert à enregistrer les pointages des ouvriers.
Actuellement, si une erreur survient, le programme s'arrête et le point age ne peut plus s'effectuer et il en découle toute une série d'emmerdeme nts.
Comment peut-on gérer les erreurs et éviter que le programme ne s'arr ête ? Peut-on créer un journal des erreurs et comment fait-on ?
Merci pour vos idées
Giques
Hello,
La méthode la plus classique (qui est loin d'être la meilleure) est d'ajouter On Error Resume Next en tête de chaque procédure... La raison pour laquelle ceci est à proscrire est qu'ignorer les erreurs 1. Ne les arrange pas 2. Peut conduire à des erreurs plus graves (et éventuellement à la persistance - dans le sens écriture dans un fichier - de ces erreurs)
La méthode appropriée est souvent: 1. D'écrire des objets business possédant des fonctions qui testent "suffisament" leurs paramètres/état que pour échouer correctement (Soit par Err.Raise ou par retour d'un code d'erreur) 2. De trapper ces erreurs volontaires (ou involontaires) dans les classes servant de façade avec la couche "suivante" de manière cohérente, tout en fournissant la possibilité à cette couche de pouvoir déterminer le succès ou non de l'opération effectuée d'un point de vue global. En cas d'échec il est important de renvoyer une erreur de "suffisament" haut niveau, mais permettant de remonter "suffisament" que pour déterminer l'origine de l'erreur (une erreur "Mémoire insuffisante" sans autre précision est aussi inutile pour l'utilisateur qu'elle ne l'est pour le développeur) 3. De détecter les échecs (et les erreurs éventuelles) dans la plus haute couche (c à d l'interface utilisateur - bien que celle-ci devrait contenir suffisament peu de code que pour que les erreurs soient improbables) et de les signaler à l'utilisateur, éventuellement en proposant de quitter ou d'annuler l'opération. Trapper les erreur se fait à l'aide de On Error Goto Label.
Pour transcrire les erreurs dans le system log, je te réfère à la documentation de la méthode LogEvent de l'objet App: http://msdn2.microsoft.com/en-us/library/aa244132(VS.60).aspx
François
On Sep 12, 10:22 am, "Giques" <AS_gilbert.charl...@versateladsl.be>
wrote:
Bonjour à tous,
J'ai un programme qui doit tourner en permanence sur un ordinateur, ce
programme sert à enregistrer les pointages des ouvriers.
Actuellement, si une erreur survient, le programme s'arrête et le point age
ne peut plus s'effectuer et il en découle toute une série d'emmerdeme nts.
Comment peut-on gérer les erreurs et éviter que le programme ne s'arr ête ?
Peut-on créer un journal des erreurs et comment fait-on ?
Merci pour vos idées
Giques
Hello,
La méthode la plus classique (qui est loin d'être la meilleure) est
d'ajouter On Error Resume Next en tête de chaque procédure... La
raison pour laquelle ceci est à proscrire est qu'ignorer les erreurs
1. Ne les arrange pas
2. Peut conduire à des erreurs plus graves (et éventuellement à la
persistance - dans le sens écriture dans un fichier - de ces erreurs)
La méthode appropriée est souvent:
1. D'écrire des objets business possédant des fonctions qui testent
"suffisament" leurs paramètres/état que pour échouer correctement
(Soit par Err.Raise ou par retour d'un code d'erreur)
2. De trapper ces erreurs volontaires (ou involontaires) dans les
classes servant de façade avec la couche "suivante" de manière
cohérente, tout en fournissant la possibilité à cette couche de
pouvoir déterminer le succès ou non de l'opération effectuée d'un
point de vue global. En cas d'échec il est important de renvoyer une
erreur de "suffisament" haut niveau, mais permettant de remonter
"suffisament" que pour déterminer l'origine de l'erreur (une erreur
"Mémoire insuffisante" sans autre précision est aussi inutile pour
l'utilisateur qu'elle ne l'est pour le développeur)
3. De détecter les échecs (et les erreurs éventuelles) dans la plus
haute couche (c à d l'interface utilisateur - bien que celle-ci
devrait contenir suffisament peu de code que pour que les erreurs
soient improbables) et de les signaler à l'utilisateur, éventuellement
en proposant de quitter ou d'annuler l'opération.
Trapper les erreur se fait à l'aide de On Error Goto Label.
Pour transcrire les erreurs dans le system log, je te réfère à la
documentation de la méthode LogEvent de l'objet App:
http://msdn2.microsoft.com/en-us/library/aa244132(VS.60).aspx
J'ai un programme qui doit tourner en permanence sur un ordinateur, ce programme sert à enregistrer les pointages des ouvriers.
Actuellement, si une erreur survient, le programme s'arrête et le point age ne peut plus s'effectuer et il en découle toute une série d'emmerdeme nts.
Comment peut-on gérer les erreurs et éviter que le programme ne s'arr ête ? Peut-on créer un journal des erreurs et comment fait-on ?
Merci pour vos idées
Giques
Hello,
La méthode la plus classique (qui est loin d'être la meilleure) est d'ajouter On Error Resume Next en tête de chaque procédure... La raison pour laquelle ceci est à proscrire est qu'ignorer les erreurs 1. Ne les arrange pas 2. Peut conduire à des erreurs plus graves (et éventuellement à la persistance - dans le sens écriture dans un fichier - de ces erreurs)
La méthode appropriée est souvent: 1. D'écrire des objets business possédant des fonctions qui testent "suffisament" leurs paramètres/état que pour échouer correctement (Soit par Err.Raise ou par retour d'un code d'erreur) 2. De trapper ces erreurs volontaires (ou involontaires) dans les classes servant de façade avec la couche "suivante" de manière cohérente, tout en fournissant la possibilité à cette couche de pouvoir déterminer le succès ou non de l'opération effectuée d'un point de vue global. En cas d'échec il est important de renvoyer une erreur de "suffisament" haut niveau, mais permettant de remonter "suffisament" que pour déterminer l'origine de l'erreur (une erreur "Mémoire insuffisante" sans autre précision est aussi inutile pour l'utilisateur qu'elle ne l'est pour le développeur) 3. De détecter les échecs (et les erreurs éventuelles) dans la plus haute couche (c à d l'interface utilisateur - bien que celle-ci devrait contenir suffisament peu de code que pour que les erreurs soient improbables) et de les signaler à l'utilisateur, éventuellement en proposant de quitter ou d'annuler l'opération. Trapper les erreur se fait à l'aide de On Error Goto Label.
Pour transcrire les erreurs dans le system log, je te réfère à la documentation de la méthode LogEvent de l'objet App: http://msdn2.microsoft.com/en-us/library/aa244132(VS.60).aspx
François
Christian Hugoud
Hi,
Personnellement, j'ai un gestionnaire d'erreur par procédure ou fonction. Celui-ci appelle une fonction publique (vue de toute l'appli) de gestion d'erreur, qui renvoie ce qu'il faut faire (ignore, retry, abort).
L'important, selon moi, est de passer à cette fonction le nom de la procédure qui est à la source de l'erreur. Cela permet de debugger directement au bon endroit.
Voici un exemple : 'une de mes nombreuses procédures.... Private Sub AddDirSep(strPathName As String) On Error GoTo error_manager
If Right(Trim(strPathName), Len("/")) <> "/" And Right(Trim(strPathName), Len("/")) <> "" Then strPathName = RTrim$(strPathName) & "" End If
Exit Sub
error_manager: If ErrorManager(Err, Error, "AddDirSep") = Retry Then Resume Else Resume Next End Sub
note bien ici que l'on passe le nom de la procédure au gestionnaire d'erreur (AddDirSep) : If ErrorManager(Err, Error, "AddDirSep") = Retry Then Resume Else Resume Next
et voila le gestionnaire d'erreur : Public Enum cErrorManager Ignore = 1 Retry = 2 Abort = 3 End Enum
Public Function ErrorManager(ByVal ErrId&, ByVal ErrorText$, ByVal ProcName$) As cErrorManager On Error Resume Next Dim str$
Select Case MsgBox(str, vbAbortRetryIgnore + vbCritical, "")'affichage du message avec proposition de choix Case vbIgnore ErrorManager = Ignore Case vbRetry ErrorManager = Retry Case vbAbort ErrorManager = Abort End 'arrêt brutal : à éviter End Select
End Function
C'est ici que tu peux écrire dans un fichier ce qui se passe. Note qu'ici, l'utilisateur doit faire un choix. Tu pourrais détecter le niveau d'erreur (complexe au final) et décider à la place de l'utilisateur.
Hope this helps
Christian
"Giques" a écrit dans le message de news: 46e7a1ba$0$7365$
Bonjour à tous,
J'ai un programme qui doit tourner en permanence sur un ordinateur, ce programme sert à enregistrer les pointages des ouvriers.
Actuellement, si une erreur survient, le programme s'arrête et le pointage ne peut plus s'effectuer et il en découle toute une série d'emmerdements.
Comment peut-on gérer les erreurs et éviter que le programme ne s'arrête ? Peut-on créer un journal des erreurs et comment fait-on ?
Merci pour vos idées
Giques
Hi,
Personnellement, j'ai un gestionnaire d'erreur par procédure ou fonction.
Celui-ci appelle une fonction publique (vue de toute l'appli) de gestion
d'erreur, qui renvoie ce qu'il faut faire (ignore, retry, abort).
L'important, selon moi, est de passer à cette fonction le nom de la
procédure qui est à la source de l'erreur. Cela permet de debugger
directement au bon endroit.
Voici un exemple :
'une de mes nombreuses procédures....
Private Sub AddDirSep(strPathName As String)
On Error GoTo error_manager
If Right(Trim(strPathName), Len("/")) <> "/" And Right(Trim(strPathName),
Len("/")) <> "" Then
strPathName = RTrim$(strPathName) & ""
End If
Exit Sub
error_manager:
If ErrorManager(Err, Error, "AddDirSep") = Retry Then Resume Else Resume
Next
End Sub
note bien ici que l'on passe le nom de la procédure au gestionnaire d'erreur
(AddDirSep) :
If ErrorManager(Err, Error, "AddDirSep") = Retry Then Resume Else Resume
Next
et voila le gestionnaire d'erreur :
Public Enum cErrorManager
Ignore = 1
Retry = 2
Abort = 3
End Enum
Public Function ErrorManager(ByVal ErrId&, ByVal ErrorText$, ByVal
ProcName$) As cErrorManager
On Error Resume Next
Dim str$
Select Case MsgBox(str, vbAbortRetryIgnore + vbCritical, "")'affichage du
message avec proposition de choix
Case vbIgnore
ErrorManager = Ignore
Case vbRetry
ErrorManager = Retry
Case vbAbort
ErrorManager = Abort
End 'arrêt brutal : à éviter
End Select
End Function
C'est ici que tu peux écrire dans un fichier ce qui se passe. Note qu'ici,
l'utilisateur doit faire un choix. Tu pourrais détecter le niveau d'erreur
(complexe au final) et décider à la place de l'utilisateur.
Hope this helps
Christian
"Giques" <AS_gilbert.charlier@versateladsl.be> a écrit dans le message de
news: 46e7a1ba$0$7365$4d4efb8e@read.news.be.uu.net...
Bonjour à tous,
J'ai un programme qui doit tourner en permanence sur un ordinateur, ce
programme sert à enregistrer les pointages des ouvriers.
Actuellement, si une erreur survient, le programme s'arrête et le pointage
ne peut plus s'effectuer et il en découle toute une série d'emmerdements.
Comment peut-on gérer les erreurs et éviter que le programme ne s'arrête ?
Peut-on créer un journal des erreurs et comment fait-on ?
Personnellement, j'ai un gestionnaire d'erreur par procédure ou fonction. Celui-ci appelle une fonction publique (vue de toute l'appli) de gestion d'erreur, qui renvoie ce qu'il faut faire (ignore, retry, abort).
L'important, selon moi, est de passer à cette fonction le nom de la procédure qui est à la source de l'erreur. Cela permet de debugger directement au bon endroit.
Voici un exemple : 'une de mes nombreuses procédures.... Private Sub AddDirSep(strPathName As String) On Error GoTo error_manager
If Right(Trim(strPathName), Len("/")) <> "/" And Right(Trim(strPathName), Len("/")) <> "" Then strPathName = RTrim$(strPathName) & "" End If
Exit Sub
error_manager: If ErrorManager(Err, Error, "AddDirSep") = Retry Then Resume Else Resume Next End Sub
note bien ici que l'on passe le nom de la procédure au gestionnaire d'erreur (AddDirSep) : If ErrorManager(Err, Error, "AddDirSep") = Retry Then Resume Else Resume Next
et voila le gestionnaire d'erreur : Public Enum cErrorManager Ignore = 1 Retry = 2 Abort = 3 End Enum
Public Function ErrorManager(ByVal ErrId&, ByVal ErrorText$, ByVal ProcName$) As cErrorManager On Error Resume Next Dim str$
Select Case MsgBox(str, vbAbortRetryIgnore + vbCritical, "")'affichage du message avec proposition de choix Case vbIgnore ErrorManager = Ignore Case vbRetry ErrorManager = Retry Case vbAbort ErrorManager = Abort End 'arrêt brutal : à éviter End Select
End Function
C'est ici que tu peux écrire dans un fichier ce qui se passe. Note qu'ici, l'utilisateur doit faire un choix. Tu pourrais détecter le niveau d'erreur (complexe au final) et décider à la place de l'utilisateur.
Hope this helps
Christian
"Giques" a écrit dans le message de news: 46e7a1ba$0$7365$
Bonjour à tous,
J'ai un programme qui doit tourner en permanence sur un ordinateur, ce programme sert à enregistrer les pointages des ouvriers.
Actuellement, si une erreur survient, le programme s'arrête et le pointage ne peut plus s'effectuer et il en découle toute une série d'emmerdements.
Comment peut-on gérer les erreurs et éviter que le programme ne s'arrête ? Peut-on créer un journal des erreurs et comment fait-on ?
Merci pour vos idées
Giques
Olivier B.
On Wed, 12 Sep 2007 10:22:55 +0200, "Giques" wrote:
Bonjour à tous,
J'ai un programme qui doit tourner en permanence sur un ordinateur, ce programme sert à enregistrer les pointages des ouvriers.
Actuellement, si une erreur survient, le programme s'arrête et le pointage ne peut plus s'effectuer et il en découle toute une série d'emmerdements.
Comment peut-on gérer les erreurs et éviter que le programme ne s'arrête ? Peut-on créer un journal des erreurs et comment fait-on ?
je sais que c'est bourrin mais en attendant que ton soft soit depollué en interne tu peux gérer ça d'une maniere externe en le lancant à partir d'un batch qui rebouclera sur lui meme ainsi le soft fermé il se relance.
-- http://olivier.2a.free.fr/ pas de turlututu. apres l'@robase
On Wed, 12 Sep 2007 10:22:55 +0200, "Giques"
<AS_gilbert.charlier@versateladsl.be> wrote:
Bonjour à tous,
J'ai un programme qui doit tourner en permanence sur un ordinateur, ce
programme sert à enregistrer les pointages des ouvriers.
Actuellement, si une erreur survient, le programme s'arrête et le pointage
ne peut plus s'effectuer et il en découle toute une série d'emmerdements.
Comment peut-on gérer les erreurs et éviter que le programme ne s'arrête ?
Peut-on créer un journal des erreurs et comment fait-on ?
je sais que c'est bourrin mais en attendant que ton soft soit depollué
en interne tu peux gérer ça d'une maniere externe en le lancant à
partir d'un batch qui rebouclera sur lui meme ainsi le soft fermé il
se relance.
--
http://olivier.2a.free.fr/
pas de turlututu. apres l'@robase
On Wed, 12 Sep 2007 10:22:55 +0200, "Giques" wrote:
Bonjour à tous,
J'ai un programme qui doit tourner en permanence sur un ordinateur, ce programme sert à enregistrer les pointages des ouvriers.
Actuellement, si une erreur survient, le programme s'arrête et le pointage ne peut plus s'effectuer et il en découle toute une série d'emmerdements.
Comment peut-on gérer les erreurs et éviter que le programme ne s'arrête ? Peut-on créer un journal des erreurs et comment fait-on ?
je sais que c'est bourrin mais en attendant que ton soft soit depollué en interne tu peux gérer ça d'une maniere externe en le lancant à partir d'un batch qui rebouclera sur lui meme ainsi le soft fermé il se relance.
-- http://olivier.2a.free.fr/ pas de turlututu. apres l'@robase
Patrice Henrio
les problèmes de cette méthode sont multiples : si le programme gère des données en écriture : pollution éventuelle des données puis boucle sans fin s'il ne libère pas la mémoire du fait du crash : tu vas rapidement atteindre la saturation
la solution du gestionnaire d'erreurs est la seule valable.
Le mieux serait sans doute de vérifier la validité des arguments dans toutes tes sub.
De toutes façons tu ne pourras rien contre les micro-coupures et surtout les erreurs provenant de la pointeuse qui doit être reliée à l'ordi. Encore que pour ce dernier point un test de validité du signal doit pouvoir ce faire.
"Olivier B." a écrit dans le message de news:
On Wed, 12 Sep 2007 10:22:55 +0200, "Giques" wrote:
Bonjour à tous,
J'ai un programme qui doit tourner en permanence sur un ordinateur, ce programme sert à enregistrer les pointages des ouvriers.
Actuellement, si une erreur survient, le programme s'arrête et le pointage ne peut plus s'effectuer et il en découle toute une série d'emmerdements.
Comment peut-on gérer les erreurs et éviter que le programme ne s'arrête ? Peut-on créer un journal des erreurs et comment fait-on ?
je sais que c'est bourrin mais en attendant que ton soft soit depollué en interne tu peux gérer ça d'une maniere externe en le lancant à partir d'un batch qui rebouclera sur lui meme ainsi le soft fermé il se relance.
-- http://olivier.2a.free.fr/ pas de turlututu. apres l'@robase
les problèmes de cette méthode sont multiples :
si le programme gère des données en écriture : pollution éventuelle des
données puis boucle sans fin
s'il ne libère pas la mémoire du fait du crash : tu vas rapidement atteindre
la saturation
la solution du gestionnaire d'erreurs est la seule valable.
Le mieux serait sans doute de vérifier la validité des arguments dans toutes
tes sub.
De toutes façons tu ne pourras rien contre les micro-coupures et surtout les
erreurs provenant de la pointeuse qui doit être reliée à l'ordi. Encore que
pour ce dernier point un test de validité du signal doit pouvoir ce faire.
"Olivier B." <olivier.2a@turlututu.free.fr> a écrit dans le message de news:
u1vte3hssc0013u05jildeh1gvkkffqn6o@4ax.com...
On Wed, 12 Sep 2007 10:22:55 +0200, "Giques"
<AS_gilbert.charlier@versateladsl.be> wrote:
Bonjour à tous,
J'ai un programme qui doit tourner en permanence sur un ordinateur, ce
programme sert à enregistrer les pointages des ouvriers.
Actuellement, si une erreur survient, le programme s'arrête et le pointage
ne peut plus s'effectuer et il en découle toute une série d'emmerdements.
Comment peut-on gérer les erreurs et éviter que le programme ne s'arrête ?
Peut-on créer un journal des erreurs et comment fait-on ?
je sais que c'est bourrin mais en attendant que ton soft soit depollué
en interne tu peux gérer ça d'une maniere externe en le lancant à
partir d'un batch qui rebouclera sur lui meme ainsi le soft fermé il
se relance.
--
http://olivier.2a.free.fr/
pas de turlututu. apres l'@robase
les problèmes de cette méthode sont multiples : si le programme gère des données en écriture : pollution éventuelle des données puis boucle sans fin s'il ne libère pas la mémoire du fait du crash : tu vas rapidement atteindre la saturation
la solution du gestionnaire d'erreurs est la seule valable.
Le mieux serait sans doute de vérifier la validité des arguments dans toutes tes sub.
De toutes façons tu ne pourras rien contre les micro-coupures et surtout les erreurs provenant de la pointeuse qui doit être reliée à l'ordi. Encore que pour ce dernier point un test de validité du signal doit pouvoir ce faire.
"Olivier B." a écrit dans le message de news:
On Wed, 12 Sep 2007 10:22:55 +0200, "Giques" wrote:
Bonjour à tous,
J'ai un programme qui doit tourner en permanence sur un ordinateur, ce programme sert à enregistrer les pointages des ouvriers.
Actuellement, si une erreur survient, le programme s'arrête et le pointage ne peut plus s'effectuer et il en découle toute une série d'emmerdements.
Comment peut-on gérer les erreurs et éviter que le programme ne s'arrête ? Peut-on créer un journal des erreurs et comment fait-on ?
je sais que c'est bourrin mais en attendant que ton soft soit depollué en interne tu peux gérer ça d'une maniere externe en le lancant à partir d'un batch qui rebouclera sur lui meme ainsi le soft fermé il se relance.
-- http://olivier.2a.free.fr/ pas de turlututu. apres l'@robase
Giques
Merci à tous pour ces infos.
Giques
"Patrice Henrio" a écrit dans le message de news: eXUoYmc%
les problèmes de cette méthode sont multiples : si le programme gère des données en écriture : pollution éventuelle des données puis boucle sans fin s'il ne libère pas la mémoire du fait du crash : tu vas rapidement atteindre la saturation
la solution du gestionnaire d'erreurs est la seule valable.
Le mieux serait sans doute de vérifier la validité des arguments dans toutes tes sub.
De toutes façons tu ne pourras rien contre les micro-coupures et surtout les erreurs provenant de la pointeuse qui doit être reliée à l'ordi. Encore que pour ce dernier point un test de validité du signal doit pouvoir ce faire.
"Olivier B." a écrit dans le message de news:
On Wed, 12 Sep 2007 10:22:55 +0200, "Giques" wrote:
Bonjour à tous,
J'ai un programme qui doit tourner en permanence sur un ordinateur, ce programme sert à enregistrer les pointages des ouvriers.
Actuellement, si une erreur survient, le programme s'arrête et le pointage ne peut plus s'effectuer et il en découle toute une série d'emmerdements.
Comment peut-on gérer les erreurs et éviter que le programme ne s'arrête ? Peut-on créer un journal des erreurs et comment fait-on ?
je sais que c'est bourrin mais en attendant que ton soft soit depollué en interne tu peux gérer ça d'une maniere externe en le lancant à partir d'un batch qui rebouclera sur lui meme ainsi le soft fermé il se relance.
-- http://olivier.2a.free.fr/ pas de turlututu. apres l'@robase
Merci à tous pour ces infos.
Giques
"Patrice Henrio" <patrice.henrio@laposte.net> a écrit dans le message de
news: eXUoYmc%23HHA.5160@TK2MSFTNGP05.phx.gbl...
les problèmes de cette méthode sont multiples :
si le programme gère des données en écriture : pollution éventuelle des
données puis boucle sans fin
s'il ne libère pas la mémoire du fait du crash : tu vas rapidement
atteindre la saturation
la solution du gestionnaire d'erreurs est la seule valable.
Le mieux serait sans doute de vérifier la validité des arguments dans
toutes tes sub.
De toutes façons tu ne pourras rien contre les micro-coupures et surtout
les erreurs provenant de la pointeuse qui doit être reliée à l'ordi.
Encore que pour ce dernier point un test de validité du signal doit
pouvoir ce faire.
"Olivier B." <olivier.2a@turlututu.free.fr> a écrit dans le message de
news: u1vte3hssc0013u05jildeh1gvkkffqn6o@4ax.com...
On Wed, 12 Sep 2007 10:22:55 +0200, "Giques"
<AS_gilbert.charlier@versateladsl.be> wrote:
Bonjour à tous,
J'ai un programme qui doit tourner en permanence sur un ordinateur, ce
programme sert à enregistrer les pointages des ouvriers.
Actuellement, si une erreur survient, le programme s'arrête et le
pointage
ne peut plus s'effectuer et il en découle toute une série d'emmerdements.
Comment peut-on gérer les erreurs et éviter que le programme ne s'arrête
?
Peut-on créer un journal des erreurs et comment fait-on ?
je sais que c'est bourrin mais en attendant que ton soft soit depollué
en interne tu peux gérer ça d'une maniere externe en le lancant à
partir d'un batch qui rebouclera sur lui meme ainsi le soft fermé il
se relance.
--
http://olivier.2a.free.fr/
pas de turlututu. apres l'@robase
"Patrice Henrio" a écrit dans le message de news: eXUoYmc%
les problèmes de cette méthode sont multiples : si le programme gère des données en écriture : pollution éventuelle des données puis boucle sans fin s'il ne libère pas la mémoire du fait du crash : tu vas rapidement atteindre la saturation
la solution du gestionnaire d'erreurs est la seule valable.
Le mieux serait sans doute de vérifier la validité des arguments dans toutes tes sub.
De toutes façons tu ne pourras rien contre les micro-coupures et surtout les erreurs provenant de la pointeuse qui doit être reliée à l'ordi. Encore que pour ce dernier point un test de validité du signal doit pouvoir ce faire.
"Olivier B." a écrit dans le message de news:
On Wed, 12 Sep 2007 10:22:55 +0200, "Giques" wrote:
Bonjour à tous,
J'ai un programme qui doit tourner en permanence sur un ordinateur, ce programme sert à enregistrer les pointages des ouvriers.
Actuellement, si une erreur survient, le programme s'arrête et le pointage ne peut plus s'effectuer et il en découle toute une série d'emmerdements.
Comment peut-on gérer les erreurs et éviter que le programme ne s'arrête ? Peut-on créer un journal des erreurs et comment fait-on ?
je sais que c'est bourrin mais en attendant que ton soft soit depollué en interne tu peux gérer ça d'une maniere externe en le lancant à partir d'un batch qui rebouclera sur lui meme ainsi le soft fermé il se relance.
-- http://olivier.2a.free.fr/ pas de turlututu. apres l'@robase
