Gestion des exceptions

Avertissement préliminaire: la sécurité face aux exceptions n'est pas encore au point ! Les cas courants devraient fonctionner, mais les classes peuvent encore présenter des fuites de mémoire, voire provoquer des plantages.

Qt ne lève pas d'exceptions en soi. À la place, des codes d'erreur sont utilisés. De plus, certaines classes disposent de messages d'erreur visibles par l'utilisateur, par exemple QIODevice::errorString() ou QSqlQuery::lastError(). Cela s'explique par des raisons historiques et pratiques : l'activation des exceptions peut augmenter la taille de la bibliothèque de plus de 20 %.

Les sections suivantes décrivent le comportement de Qt lorsque la prise en charge des exceptions est activée lors de la compilation.

Modules sans risque d’exception

Conteneurs

Les classes de conteneurs de Qt sont généralement neutres vis-à-vis des exceptions. Elles transmettent à l’utilisateur toute exception survenant au sein de T de type qu’elles contiennent, tout en conservant la validité de leur état interne.

Exemple :

QList<QString> list;
...
try {
    list.append("hello");
} catch (...) {
}
// list is safe to use - the exception did not affect it.

Les exceptions à cette règle concernent les conteneurs destinés à des types pouvant lever une exception lors de la construction par affectation ou par copie. Pour ces types, les fonctions qui modifient le conteneur tout en renvoyant une valeur ne doivent pas être utilisées :

MyType s = list.takeAt(2);

Si une exception se produit lors de l'affectation de ` s`, la valeur à l'index 2 est déjà supprimée du conteneur, mais n'a pas encore été affectée à ` s `. Elle est perdue sans possibilité de récupération.

Voici la manière correcte de l'écrire :

MyType s = list.at(2);
list.removeAt(2);

Si l'affectation génère une exception, le conteneur contiendra toujours la valeur ; aucune perte de données ne s'est produite.

Notez que les classes Qt à partage implicite ne déclenchent pas d'exception dans leurs opérateurs d'affectation ou leurs constructeurs de copie ; la restriction ci-dessus ne s'applique donc pas.

Gestion des problèmes de mémoire insuffisante

La plupart des systèmes d’exploitation de bureau pratiquent la surallocation de mémoire. Cela signifie que les fonctions ` malloc() ` ou ` operator new ` renvoient un pointeur valide, même s’il n’y a pas suffisamment de mémoire disponible au moment de l’allocation. Sur ces systèmes, aucune exception de type ` std::bad_alloc ` n’est levée.

Sur tous les autres systèmes d'exploitation, Qt lèvera une exception de type std::bad_alloc si une allocation échoue. Les allocations peuvent échouer si le système est à court de mémoire ou s'il ne dispose pas de suffisamment de mémoire contiguë pour allouer la taille demandée.

Les exceptions à cette règle sont documentées. À titre d’exemple, les constructeurs de ` QImage ` créeront une image ` null ` s’il n’y a pas assez de mémoire, au lieu de lever une exception.

Gestion des exceptions

Actuellement, le seul cas d'utilisation pris en charge pour la gestion des exceptions levées au sein de Qt (par exemple en raison d'un manque de mémoire) consiste à quitter la boucle d'événements et à effectuer quelques opérations de nettoyage avant de fermer l'application.

Cas d'utilisation typique :

QApplication app(argc, argv);
...
int ret;
try {
    ret = app.exec();
} catch (const std::bad_alloc &) {
    // clean up here, e.g. save the session
    // and close all config files.

    return EXIT_FAILURE; // exit the application
}
...
return ret;

Une fois qu'une exception a été levée, la connexion au serveur de fenêtrage peut déjà être fermée. Il n'est pas sûr d'appeler une fonction liée à l'interface graphique après avoir intercepté une exception.

Exceptions dans le code client

Signaux et slots

Le fait de lancer une exception depuis un slot appelé par le mécanisme de connexion signal-slot de Qt est considéré comme un comportement indéfini, à moins que cette exception ne soit gérée au sein même du slot :

State state;
StateListener stateListener;

// OK; the exception is handled before it leaves the slot.
QObject::connect(&state, SIGNAL(stateChanged()), &stateListener, SLOT(throwHandledException()));
// Undefined behaviour; upon invocation of the slot, the exception will be propagated to the
// point of emission, unwinding the stack of the Qt code (which is not guaranteed to be exception safe).
QObject::connect(&state, SIGNAL(stateChanged()), &stateListener, SLOT(throwUnhandledException()));

Si le slot a été appelé directement, comme un appel de fonction classique, les exceptions peuvent être utilisées. En effet, le mécanisme de connexion est contourné lors de l'appel direct des slots :

State state;
StateListener stateListener;

// ...

try {
    // OK ; appel direct du slot.
    stateListener.throwException();
} catch (...) {
    qDebug() << "Handling exception not caught in slot.";
}