Viadeo Twitter Google Bookmarks ! Facebook Digg del.icio.us MySpace Yahoo MyWeb Blinklist Netvouz Reddit Simpy StumbleUpon Bookmarks Windows Live Favorites 
Logo Documentation Qt ·  Page d'accueil  ·  Toutes les classes  ·  Toutes les fonctions  ·  Vues d'ensemble  · 

Exception Safety

Preliminary warning: Exception safety is not feature complete! Common cases should work, but classes might still leak or even crash.

Qt itself will not throw exceptions. Instead, error codes are used. In addition, some classes have user visible error messages, for example QIODevice::errorString() or QSqlQuery::lastError(). This has historical and practical reasons - turning on exceptions can increase the library size by over 20%.

The following sections describe Qt's behavior if exception support is enabled at compile time.

Exception safe modules

Containers

Qt's container classes are generally exception neutral. They pass any exception that happens within their contained type T to the user while keeping their internal state valid.

Example:

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

Exceptions to that rule are containers for types that can throw during assignment or copy constructions. For those types, functions that modify the container as well as returning a value, are unsafe to use:

 MyType s = list.takeAt(2);

If an exception occurs during the assignment of s, the value at index 2 is already removed from the container, but hasn't been assigned to s yet. It is lost without chance of recovery.

The correct way to write it:

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

If the assignment throws, the container still contains the value, no data loss occured.

Note that implicitly shared Qt classes will not throw in their assignment operators or copy constructors, so the limitation above does not apply.

Out of Memory Handling

Most desktop operating systems overcommit memory. This means that malloc() or operator new return a valid pointer, even though there is not enough memory available at allocation time. On such systems, no exception of type std::bad_alloc is thrown.

On all other operating systems, Qt will throw an exception of type std::bad_alloc if any allocation fails. Allocations can fail if the system runs out of memory or doesn't have enough continuous memory to allocate the requested size.

Exceptions to that rule are documented. As an example, QImage constructors will create a null image if not enough memory exists instead of throwing an exception.

Recovering from exceptions

Currently, the only supported use case for recovering from exceptions thrown within Qt (for example due to out of memory) is to exit the event loop and do some cleanup before exiting the application.

Typical use case:

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

     return 0; // exit the application
 }

After an exception is thrown, the connection to the windowing server might already be closed. It is not safe to call a GUI related function after catching an exception.

Platform-Specific Exception Handling

The Symbian platform

The Symbian platform implements its own exception system that differs from the standard C++ mechanism. When using Qt for the Symbian platform, and especially when writing code to access Symbian functionality directly, it may be necessary to know about the underlying implementation and how it interacts with Qt.

The Exception Safety with Symbian document shows how to use the facilities provided by Qt to use exceptions as safely as possible.

Publicité

Best Of

Actualités les plus lues

Semaine
Mois
Année
  1. « Quelque chose ne va vraiment pas avec les développeurs "modernes" », un développeur à "l'ancienne" critique la multiplication des bibliothèques 64
  2. Apercevoir la troisième dimension ou l'utilisation multithreadée d'OpenGL dans Qt, un article des Qt Quarterly traduit par Guillaume Belz 0
  3. Les développeurs ignorent-ils trop les failles découvertes dans leur code ? Prenez-vous en compte les remarques des autres ? 17
  4. BlackBerry 10 : premières images du prochain OS de RIM qui devrait intégrer des widgets et des tuiles inspirées de Windows Phone 0
  5. Quelles nouveautés de C++11 Visual C++ doit-il rapidement intégrer ? Donnez-nous votre avis 10
  6. Adieu qmake, bienvenue qbs : Qt Building Suite, un outil déclaratif et extensible pour la compilation de projets Qt 17
  7. La rubrique Qt a besoin de vous ! 1
Page suivante

Le Qt Developer Network au hasard

Logo

Comment fermer une application

Le Qt Developer Network est un réseau de développeurs Qt anglophone, où ils peuvent partager leur expérience sur le framework. Lire l'article.

Communauté

Ressources

Liens utiles

Contact

  • Vous souhaitez rejoindre la rédaction ou proposer un tutoriel, une traduction, une question... ? Postez dans le forum Contribuez ou contactez-nous par MP ou par email (voir en bas de page).

Qt dans le magazine

Cette page est une traduction d'une page de la documentation de Qt, écrite par Nokia Corporation and/or its subsidiary(-ies). Les éventuels problèmes résultant d'une mauvaise traduction ne sont pas imputables à Nokia. Qt 4.7
Copyright © 2012 Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon, vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. Cette page est déposée à la SACD.
Vous avez déniché une erreur ? Un bug ? Une redirection cassée ? Ou tout autre problème, quel qu'il soit ? Ou bien vous désirez participer à ce projet de traduction ? N'hésitez pas à nous contacter ou par MP !
 
 
 
 
Partenaires

Hébergement Web