Discussion :

[_skip]

Bonjour,

Comme vous le savez sûrement, pour différentes raisons, Qt n'utilise pas les exceptions dans sa bibliothèque. Ceci me pose pas mal de problèmes, notamment lorsque j'utilise des QTextStream ou QDataStream par dessus des QFile (échec 100% silencieux).

Mais même pour le reste, je serai intéressé de savoir quelles sont vos stratégies de gestion d'erreur, si vous avez tendance à utiliser des wrappers par dessus les objets QT qui eux lancent des exceptions ou si vous travaillez avec des valeurs de retour spécialisées...

Je suis à la recherche de conseils en la matière...
Merci d'avance

[LittleWhite]

Je suis plus pour des valeurs de retour spécialisée ( tendance à ne pas trop aimé les exceptions ( à tord ) ).

Après pour le QDataStream, chez moi, quand il y avait echec, il était vide ... donc même si je lisais dedans, je n'avais pas de problème.

[_skip]

Je suis plus pour des valeurs de retour spécialisée ( tendance à ne pas trop aimé les exceptions ( à tord ) ).

Sur certains points j'ai commencé à simplement lancer de bêtes QString comme exceptions. Pour simplifier car c'est un algo très court.

Après pour le QDataStream, chez moi, quand il y avait echec, il était vide ... donc même si je lisais dedans, je n'avais pas de problème.

C'est vrai mais là je suis sur un cas ou il est critique que je sache différencier le cas ou rien a été lu à cause d'une erreur ou si c'était simplement vide.

Pour un cas embêtant d'une classe qui représente un consommateur dans une architecture multi-thread, j'en suis arrivé à ceci :

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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
 
/**
 * Writes the content of a temporary file into the final result file.
 * The result file is assumed to be already open in write mode, after writing, content isn't flushed nor closed.
 *
 * @param tempFile A reference to a temporary file structure (or buffer), device will be opened in RO mode.
 * @param finalFile A reference to the final file, device needs to be already OPEN in Write mode.
 */
void SyncResultWriter::mergeFile(QIODevice& tempFile, QFile& finalFile )
{
    if( !tempFile.open( QIODevice::ReadOnly ) )
    {
        setError("Could not open temp file for merging!");
        return;
    }
 
    const int B_SIZE = 4096;
    char inBuffer[B_SIZE];
 
    //reads temp file block per block
    int bytesRead = tempFile.read(inBuffer, B_SIZE) ;
 
    while( bytesRead > 0 )
    {
        //write the current block to the definitive file
        if( finalFile.write( inBuffer, bytesRead ) == -1 )
        {
            setError( QString( "Error writing chunk : ") + finalFile.errorString() );
            return;
        }
 
        //next chunk
        bytesRead = tempFile.read(inBuffer, B_SIZE);
    }
 
    //if the loop was broken because of a reading error :
    if( bytesRead ==  -1 )
    {
        setError( QString( "Error reading chunk : ") + tempFile.errorString() );
        return;
    }
 
    //finalize line
    finalFile.write( "\n");
    tempFile.close();
}
 
/**
 * Informs if an error has occured somewhere during the writing process.
 * The result of this method can be tested after task completion.
 * @return True if an error occured, false otherwise.
 */
bool SyncResultWriter::hasError()
{
    return this->foundError;
}
 
/**
 * Returns the lastest error message. Use with hasError().
 * @return An error message String, or an empty String.
 */
QString SyncResultWriter::errorString()
{
    return this->errorMessage;
}
 
/**
 * Method used internally to set this object in error state.
 * @param message The error message to set. 
 */
void SyncResultWriter::setError(QString message)
{
    this->foundError = true;
    this->errorMessage = message;
}

Tester chaque lecture/écriture et mettre l'objet en status d'erreur.
A la fin du processus, le thread principal teste ces valeurs et si jamais, il sait que le résultat de l'algo est à jeter.

Mais c'est d'une lourdeur diabolique tous ces tests à chaque read/write.

[yan]

En C++, y as pas de système d'exception thread safe.
Qt implémente une solution pour les QtConcurrent. Tu peut peut être t'en inspirer.
Rien ne t'empêche d'utiliser un système d'exeption dans le thread qui va mettre à jour setError.
Ou qui par une fonction appelé par l'autre thread, re-emetter l' exception dans ce thread.

[_skip]

Non mais là j'ai un peu disgressé car la gestion d'exception inter threads est un problème dans tous les langages que je connais, on termine souvent avec des idées du style le thread qui déclenche une erreur (exception ou autre) la stocke et un autre thread la récupère le moment venu pour avertir d'utilisateur etc...

Plus directement, je souhaitais parler de l'utilisation faite des objets QT. Actuellement je teste directement les valeurs de retour de chaque écriture / lecture. Je voulais juste savoir si certains d'entre vous avaient peut être tendance à encapsuler les objets QT pour en faire une sorte de mini framework qui lui lancerait des exceptions, ce genre de chose...

[Aurelien.Regat-Barrel]

Les exceptions sont en général une fausse bonne idée. Elles conviennent à la gestion de cas... exceptionnels, pour lesquels le code appelant ne peut rien faire. Par exemple, tu lis un fichier, et hop il n'y a plus assez de mémoire pour continuer à bosser, que peux-tu faire ?

En revanche, tester si l'ouverture d'un fichier a réussi est quelque chose qui fait parti du flot normal d'exécution d'un programme. Et c'est la responsabilité directe de l'appelant de faire ça. Un code de retour est alors mieux adapté.

Tu trouves ton code pénible à écrire car s'il utilisait des exceptions tu pourrais faire plus concis... mais c'est une fausse impression. Quelque part dans ton logiciel il va te falloir générer les 3 messages que tu donnes à setError(). Et si tu ne le fais pas dans mergeFile(), tu vas devoir le faire ailleurs dans une fonction appelante. Alors oui le code de mergeFile() sera beaucoup + court, mais ton code appelant sera beaucoup + long :

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
try
{
    mergefile(tmp, final);
}
catch ( const FileOpenError & e )
{
    setError("Could not open temp file for merging!");
    return;
}
catch ( const FileReadError & e )
{
    setError( QString( "Error reading chunk : ") + tempFile.errorString() );
    return;
}
catch ( const FileWriteError & e )
{
    setError( QString( "Error writing chunk : ") + final.errorString() );
    return;
}

Tu ne peux pas échapper à ces lignes de code. Si tu ne les mets pas dans mergefile() tu devras les mettre ailleurs. Et je ne suis pas sûr que ce soit la meilleure des choses, car le exceptions ont ceci de particulier : elles exposent les détails d'implémentation et donc affaiblissent l'encapsulation.

En ce qui me concerne, j'ai choisi une option hybride : j'utilise une classe comme valeur de retour, c.a.d qu'au lieu d'écrire :

Code :

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

1
2
3
4
5
if( !tempFile.open( QIODevice::ReadOnly ) )
{
    setError("Could not open temp file for merging!");
    return;
}

j'écris un truc du genre :

Code :

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

1
2
3
4
if( !tempFile.open( QIODevice::ReadOnly ) )
{
    return Error( tr( "Could not open temp file for merging!" ) );
}

ou bien un truc plus fun :

Code :

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

1
2
3
4
if( !tempFile.open( QIODevice::ReadOnly ) )
{
    return Error() << tr( "Could not open temp file for merging!" );
}

et le code appelant ne se soucie jamais du type de l'erreur. Il y a "une erreur" et c'est tout, y'a pas à se poser davantage de question. Il est du genre :

Code :

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

1
2
3
4
5
Error err = mergefile();
if ( err )
{
    displayError( err );
}

Tu fais ce que tu veux de l'erreur récupérée : affichage, renvoie en code de retour, renvoie sous forme d'exception etc...

En fait, j'ai exploré une autre voie, qui est celle-ci :

Code :

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

1
2
3
4
if( !tempFile.open( QIODevice::ReadOnly ) )
{
    return Error::COULD_NOT_OPEN_FILE_FOR_MERGING;
}

dans le but de centraliser tous les messages d'erreur possibles, ce qui offre de nombreux avantages en ce qui concerne les messages affichés à l'utilisateur par une application.

Mais ça ne convient pas très bien aux messages "internes" d'un composant réutilisable par exemple. Il faut ainsi distinguer plusieurs types d'erreurs dans son application, et traiter chaque type d'une manière spécifique clairement établie. Les exceptions conviennent - il me semble - aux erreurs les + sérieuses et les + rares, qui doivent être traitée à un niveau supérieur quand elles ne nécessitent pas de fermer le programme.