Gestion des erreurs

François Picalausa

12/09/2007 à 12:04

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

François

Vous avez filtré cet utilisateur ! Consultez son message

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

Christian Hugoud

12/09/2007 à 13:21

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$

str = "The exception : " & ErrId & " occured in : " & vbCrLf & vbCrLf &
ProcName & vbCrLf & vbCrLf
str = str & ErrorText

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$

str = "The exception : " & ErrId & " occured in : " & vbCrLf & vbCrLf &
ProcName & vbCrLf & vbCrLf
str = str & ErrorText

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 ?

Merci pour vos idées

Giques

Vous avez filtré cet utilisateur ! Consultez son message

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$

str = "The exception : " & ErrId & " occured in : " & vbCrLf & vbCrLf &
ProcName & vbCrLf & vbCrLf
str = str & ErrorText

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.

18/09/2007 à 00:17

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

18/09/2007 à 10:10

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

18/09/2007 à 16:51

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

Gestion des erreurs

5 réponses

Veuillez sélectionner un problème