Votre gestion d'erreur / exception avec Qt ?

Version imprimable

16/10/2009, 10h44
_skip

Votre gestion d'erreur / exception avec Qt ?

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
17/10/2009, 13h10
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.

Citation:

Envoyé par LittleWhite

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.

Citation:

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:

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.

19/10/2009, 11h39
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.
19/10/2009, 12h28
_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...

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:

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:

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:

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:

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:

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:

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.

19/10/2009, 15h18
_skip
Tout d'abord, merci de cette réponse très développée!

Il me semble que les solutions miracles existent pas, j'aime bien l'idée d'une valeur de retour de type Error.
Code:

1 2 3 4 5 Error err = mergefile(); if ( err ) { displayError( err ); }
Mais j'ai peur que ceci détraque la lisibilité pour les méthodes qui seraient non void, c'est à dire destinée à retourner une valeur, j'apprécie déjà particulièrement le systeme copy on write qui permet de retourner des collections et des objets plutôt que d'avoir recours au smart pointers ou de passer des paramètres in/out...

Immédiatement ensuite j'ai pensé à cette même classe sous forme de template avec un membre T qui serait du type de retour prévu originalement, mais j'ai l'impression que ça risque d'être lourdingue à force.

Pour l'instant dans d'autres parties de mon code je lance des QString comme exception (message d'erreur). Je sais que c'est moche mais ceci me permet de les laisser se propager à travers 2/3 appels et de les catcher sur le point de lancement de l'opération... En faisant gaffe que ça devienne pas un plat de spaghetti.

Tout ce qui m'intéresse dans ce cas c'est effectivement de pouvoir indiquer au niveau le plus haut qu'un problème est arrivé.

Enfin je comprend qu'il existe pas de remèdes miracles.
19/10/2009, 16h25
Aurelien.Regat-Barrel

Citation:

Envoyé par _skip

Mais j'ai peur que ceci détraque la lisibilité pour les méthodes qui seraient non void, c'est à dire destinée à retourner une valeur

Ah oui je comprends. J'ai déjà vu passer des classes qui servent à ça : encapsuler une valeur de retour, une sorte de QPair en fait. Je me demande d'ailleurs si y'a pas ça dans boost. Perso je ne suis pas super fan.

Je pense qu'il faut distinguer 2 types d'erreurs :
- les messages que tu affiches à l'utilisateur
- les erreurs qui font partie d'une API

Pour les premiers je n'aime pas utiliser des exceptions, car on s'y perd vite dans le flot et le formatage du message affiché. Ca donne au final des messages d'erreur du genre :

Citation:

Configuration incorrecte : Erreur d'écriture (Echec de fwrite ligne 158 colonne 6 : "Disk is full" (0x00CFDA01).).

Parce que notre façon de générer un message d'erreur varie d'un bout de code à l'autre en fonction de notre humeur / du temps qu'on avait / d'un programmeur à l'autre / ... C'est pour ça que j'aime bien centraliser.

Ton choix de balancer un simple QString ne me choque pas trop personnellement, car je pense que la gestion des erreurs doit être simple. En tous cas je préfère ça aux horribles classes d'Exception avec 36 fonctions membre ou même des hiérarchies de classes d'exception. Mais tant qu'à faire traduit tes erreurs en utilisant tr() ;)
21/10/2009, 11h17
_skip

Merci à tous :ccool:
09/04/2010, 13h29
ymoreau

Je up car je trouve le débat intéressant et qu'il y a peut être de nouveaux avis. Pour ma part j'apprécie les exceptions dans certains cas :
- pour avoir une hiérarchie d'erreurs, et donc pouvoir les traiter chacune au niveau qui convient. Mais j'admets qu'en pratique c'est assez rare d'en avoir vraiment besoin.
- pour lancer des erreurs depuis un constructeur. Là encore c'est un cas rare mais qui peut être utile pour s'assurer qu'un objet créé est opérationnel.

Autant que possible j'utilise plutôt les valeurs de retour. Se pose alors comme dit au dessus le problème des fonctions qui retournent des valeurs.

Est-ce que certains ont d'autres stratégies plus originales ?