Discussion :

[Shypster]

Bonjour,

voici mon code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
 
private void CopyDir(string sourceDir, string destDir)
        {
            // mise en forme des chemins d'accés
            sourceDir.Replace("\\", "/");
            destDir.Replace("\\", "/");
 
            // process de copie
            DirectoryInfo dir = new DirectoryInfo(sourceDir); if (dir.Exists)
            {
                string realDestDir;
                if (dir.Root.Name != dir.Name)
                {
                    realDestDir = Path.Combine(destDir, dir.Name);
                    if (!Directory.Exists(realDestDir))
                        Directory.CreateDirectory(realDestDir);
                }
                else realDestDir = destDir;
                foreach (string d in Directory.GetDirectories(sourceDir))
                    CopyDir(d, realDestDir);
                foreach (string file in Directory.GetFiles(sourceDir))
                {
                    string fileNameDest = Path.Combine(realDestDir, Path.GetFileName(file));
                    //if (!File.Exists(fileNameDest))
                    if (File.GetLastWriteTime(file) > File.GetLastWriteTime(fileNameDest))
                    {
                        try
                        {
                            File.Copy("C:/zzz.txt", "Z:/zzz.txt", true);
                            File.Copy(file, fileNameDest, true);
                        }
                        catch (FileNotFoundException e)
                        {
                            File.Copy("C:/zzz.txt", "Z:/zzz.txt", true);
                            etat = "Erreur : " + e.Message;
                        }
                    }
                }
            }
        }

La portion du "try / catch" n'a aucun effet, pourquoi ?
La variable "etat" permet de stocker l'erreur et est déclarée comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
public string etat;

La fonction CopyDir est appelée dans un backgroundworker.

Merci.

[Nikoui]

La portion du "try / catch" n'a aucun effet, pourquoi ?

C'est à dire ?
Tu ne rentres jamais dans le catch ? (si c'est le cas, remplace le FileNotFoundException par Exception pour voir ce qui se passe)

Tu rentres dans le catch et le code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

File.Copy("C:/zzz.txt", "Z:/zzz.txt", true);

ne fait rien ? (a priori il lève lui aussi une exception)

Un peu plus de précisions ne ferait pas de mal pour t'aider

[smyley]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
                        try
                        {
                            File.Copy("C:/zzz.txt", "Z:/zzz.txt", true);
                            File.Copy(file, fileNameDest, true);
                        }
                        catch (FileNotFoundException e)
                        {
                            File.Copy("C:/zzz.txt", "Z:/zzz.txt", true);
                            etat = "Erreur : " + e.Message;
                        }

Donc :
Si le premier File.Copy génère un FileNotFoundException tu décides de refaire exactement la même chose dans le catch ... et donc d'y refaire un FileNotFoundException ...
C'était le but où c'est une faute de copie de ton code dans ton post ?

[Shypster]

Ah oui excusez moi, dans le catch je faisais un File.Copy() "bidon" pour voir si justement il rentrait dans mon catch ou non.

Le fait de remplacer FileNotFoundException par Exception ne change rien !

Mais actuellement quand l'exception est levée sur le File.Copy("C:/zzz.txt","z:/zzz.txt"); il ne rentre pas dans le catch et je ne vois pas pourquoi.

[SaumonAgile]

Dans le catch, laisse uniquement cette ligne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

etat = "Erreur : " + e.Message;

Et remplace le FileNotFoundException par IOException (voire Exception).
De cette manière une exception lancée par le copy dans le try sera catchée dans le bloc catch en dessous.

[ced600]

Je me demandais si File.Copy comprends la syntaxe suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

File.Copy("C:/zzz.txt", "Z:/zzz.txt", true);

Moi personnellement je fais plutôt du :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

File.Copy("C:\\zzz.txt", "Z:\\zzz.txt", true);

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
try
                        {
                            File.Copy("C:/zzz.txt", "Z:/zzz.txt", true);
                            File.Copy(file, fileNameDest, true);
                        }
                        catch (FileNotFoundException e)
                        {
                            File.Copy("C:/zzz.txt", "Z:/zzz.txt", true);
                            etat = "Erreur : " + e.Message;
                        }

Faire un File.Copy, même bidon, dans le catch peut te reprovoquer une erreur qui ne sera pas attraper, car plus de try. Et donc la ligne suivante ne devrait pas être exécuté.

D'où la proposition :

Dans le catch, laisse uniquement cette ligne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

etat = "Erreur : " + e.Message;

Et remplace le FileNotFoundException par IOException (voire Exception).
De cette manière une exception lancée par le copy dans le try sera catchée dans le bloc catch en dessous.

[Shypster]

Ok, ça marche voici mon code rectifié :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
 
private void CopyDir(string sourceDir, string destDir)
        {
            try
                        {
            // mise en forme des chemins d'accés
            sourceDir.Replace("\\", "/");
            destDir.Replace("\\", "/");
 
            // process de copie
            DirectoryInfo dir = new DirectoryInfo(sourceDir); if (dir.Exists)
            {
                string realDestDir;
                if (dir.Root.Name != dir.Name)
                {
                    realDestDir = Path.Combine(destDir, dir.Name);
                    if (!Directory.Exists(realDestDir))
                        Directory.CreateDirectory(realDestDir);
                }
                else realDestDir = destDir;
                foreach (string d in Directory.GetDirectories(sourceDir))
                    CopyDir(d, realDestDir);
                foreach (string file in Directory.GetFiles(sourceDir))
                {
                    string fileNameDest = Path.Combine(realDestDir, Path.GetFileName(file));
                    //if (!File.Exists(fileNameDest))
                    if (File.GetLastWriteTime(file) > File.GetLastWriteTime(fileNameDest))
                    {
 
                            //File.Copy("C:\\zzz.txt", "Z:\\zzz.txt", true);
                            File.Copy(file, fileNameDest, true);
 
                    }
                }
            }
        }
        catch (Exception e)
        {
            etat = "Erreur : " + e.Message;
        }
        }

Par contre j'ai une question subsidiaire. Lors des différentes copies je voudrais stocker toutes les erreurs qui pourraient se produire sachant que je suis dans un Backgroundworker. Et ainsi pouvoir afficher à l'utilisateur ces fameuses erreurs. Que me conseillez-vous ?

Je pensais transformer ma variable "etat" en tableau de string mais j'ai peur d'être limitée lors de grosses copies.

Merci pour votre aide, c'est super sympa.

[ced600]

Pouquoi faire des tableaux de string lorsque l'on peut faire des liste de string ?

[Nikoui]

Pour moi tu peux faire les choses de deux façon différentes pour la remontée des erreurs :
- Soit remonter les erreur en "temps réel" de façon évènementielle par exemple (tu lève un évènement à chaque nouvelle erreur, à la charge des abonnés de traiter/stocker/afficher l'erreur)
- Tu stocke ta liste d'erreur pour la retourner en fin de traitement (et là pas de miracle, que tu utilise des tableaux, des listes, etc, si tu t'attends a stocker de nombreuses erreurs et bien tu te retrouvera forcément avec une "grosse variable" en retour)

[ced600]

mouais, cela dépend de ce qu'il veut faire.
Il peut faire un thread qui met a disposition une pile, file, ou liste.
Le thread principale remplis cette pile, et le thread secondaier la vide en écrivant les données dans un fichier log. Pour éviter les problèmes de lecture et ecriture dans la pile en même temps par les 2 threads, il peut utiliser deux piles et faire un switch de pile (ou file ou liste).
Et pour les logs, il peut faire des logs rotatif.

[SaumonAgile]

Pour éviter les problèmes de lecture et ecriture dans la pile en même temps par les 2 threads, il peut utiliser deux piles et faire un switch de pile (ou file ou liste).

Je sais que tu aimes compliquer les choses, mais là, c'est un peu fort. Pour éviter les problèmes de lecture écriture, on peut utiliser simplement un lock ou même mieux un ReaderWriterLock.

[ced600]

Je sais que tu aimes compliquer les choses, mais là, c'est un peu fort. Pour éviter les problèmes de lecture écriture, on peut utiliser simplement un lock ou même mieux un ReaderWriterLock.

Ouais en fait c'était pour faire référence à quelque chose que je suis le seul à pourvoir comprendre
Bon ok, dans un projet d'école fait en c++, l'équipe dont je faisais partis avait opté pour le switch de pile sous mon impulsion motivé par des conseils du professeur nous encadrant

[Nikoui]

C'est vrai que faire du "double buffering" de pile c'est pour le moins original

[ced600]

C'est vrai que faire du "double buffering" de pile c'est pour le moins original

Bon va falloir que je résume pour que l'on comprenne pouquoi on a fait cela :
Nous étions obligé du fait de nos spécifications.
ça c du résumé

Nan mais on developpé un outil pour un tableau bord automobile.
Cette outil consiste à maintenir la vitesse de la voiture à la vitesse courante losrqu'on l'active.
Aujourd'hui c'est présent dans toutes les nouvelles autos.
Bref, notre programme pouvais être intérompue par plein d'événement généré par l'auto, comme appuis sur la pédale de frein, et il devait réagir en 0,2 secondes (si je me souviens bien) à ces événements, par exemple pour dans ce cas stoppé l'outil et rendre les commandes au conducteur.

On attrapé nos interceptions et on les mettais dans une pile. Le programme allait vérifier le contenu d'une mémoire partagé, et mettais certaine des valeurs de cette mémoires dans la piles lorsque l'on recevais un évenement tic (un truc genre entre 0,2 et 0,25 sec)

Mais avant de lire la mémoire partagé, lorsque l'on recevais le tic, on devait lire la pile pour déterminer qu'est ce qui été prioritaire à faire.
L'interuption dut à l'appuis sur une pédale (frein ou embrayage) était prioritaire par exemple.
Mais pendant que l'on fouille la pile, ne serait que pour la décharger, elle devient bloqué, et on peut se retrouver à perdre des intéruptions.
Perdre l'interuption appuis sur la pédale de frein c'est bien dommage
Donc pour éviter cela on switchait de piles, donc deux piles pour faire le même boulot, pour être sur de ne rien perdre.

Un bug la dedans et renault retire toute une série de voiture car cela provoque des accidents.

Enfin nous ce n'était qu'un projet d'école, donc aucun constructeur n'utilise nos programme. Et heuresement, parce que vu ce que certain groupe on fait, si cela avait été le cas, je serais partis vivre dans un endroit où aucune voiture ne peut accéder