Viadeo Twitter Google Bookmarks ! Facebook Digg 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 with Symbian

The following sections describe how Qt code can interoperate with Symbian's exception safety system.

What the problem is

Qt and Symbian have different exception systems. Qt works with standard C++ exceptions, whereas Symbian has its TRAP/Leave/CleanupStack system. So, what would happen if you mix the two systems? It could go wrong in a number of ways.

Clean-up ordering would be different between the two. When Symbian code leaves, the clean-up stack is cleaned up before anything else happens. After that, the objects on the call stack would be cleaned up as with a normal exception. So if there are any dependencies between stack-based and objects owned by the clean-up stack, there could be problems due to this ordering.

Symbian's XLeaveException, which is used when Symbian implements leaves as exceptions, is not derived from std::exception, so would not be caught in Qt catch statements designed to catch std::exception.

Qt's and standard C++'s std::exception derived exceptions result in program termination if they fall back to a Symbian TRAP.

These problems can be solved with barrier macros and helper functions that will translate between the two exception systems. Use them, in Qt code, whenever calling into or being called from Symbian code.

Qt calls to Symbian

When calling Symbian leaving functions from Qt code, we want to translate Symbian leaves to standard C++ exceptions. The following help is provided:

  • qt_symbian_throwIfError() takes a Symbian error code and throws an appropriate exception to represent it. This will do nothing if the error code is not in fact an error. The function is equivalent to Symbian's User::LeaveIfError.
  • q_check_ptr() takes a pointer and throws a std::bad_alloc exception if it is 0, otherwise the pointer is returned. This can be used to check the success of a non-throwing allocation, eg from malloc(). The function is equivalent to Symbian's User::LeaveIfNull.
  • QT_TRAP_THROWING() takes a Symbian leaving code fragment f and runs it under a trap harness converting any resulting error into an exception.
  • TRAP and TRAPD from the Symbian libraries can be used to convert leaves to error codes.
 HBufC* buf=0;
 // this will throw a std::bad_alloc because we've asked for too much memory
 QT_TRAP_THROWING(buf = HBufC::NewL(100000000));

 TInt pos = KStr().Locate('c');
 // pos is a good value, >= 0, so no exception is thrown

 pos = KStr().Locate('d');
 // pos == KErrNotFound, so this throws an exception

 // we are asking for a lot of memory, HBufC::New may return NULL, so check it
 HBufC *buffer = q_check_ptr(HBufC::New(1000000));

Be careful with new and CBase

When writing Qt code, new will normally throw a std::bad_alloc if the allocation fails. However this may not happen if the object being created has its own operator new. For example, CBase and derived classes have their own operator new which returns 0 and the new(ELeave) overload for a leaving operator new, neither of which does what we want. When using 2-phase construction of CBase derived objects, use new and q_check_ptr().

For example, if you have code like

 CFbsBitmap* fbsBitmap = new(ELeave) CFbsBitmap;

you can rewrite it as

 CFbsBitmap* fbsBitmap = q_check_ptr(new CFbsBitmap);

Qt called from Symbian

When Qt code is called from Symbian, we want to translate standard C++ exceptions to Symbian leaves or error codes. The following help is provided:

  • qt_symbian_exception2Error() - this takes a standard exception and gives an appropriate Symbian error code. If no mapping is known for the exception type, KErrGeneral is returned.
  • qt_symbian_exception2LeaveL() - this takes a standard exception and generates an appropriate Symbian leave.
  • QT_TRYCATCH_ERROR() - this macro takes the standard C++ code fragment f, catches any std::exceptions thrown from it, and sets err to the corresponding Symbian error code. err is set to KErrNone otherwise.
  • QT_TRYCATCH_LEAVING() - this macro takes the standard C++ code fragment f, catches any std::exceptions thrown from it, and throws a corresponding Symbian leave.
 TInt DoTickL() // called from an active object RunL, ie Symbian leaves expected
     // without the translation to Symbian Leave, we get a USER:0 panic
         int* x = new int[100000000];            // compiled as Qt code, will throw std::bad_alloc
         delete [] x;
     return 0;

Common sense things

Try to minimise the interleaving of Symbian and Qt code, every switch requires a barrier. Grouping the code styles in different blocks will minimise the problems. For instance, examine the following code.

 1.    TRAPD(err, m_playUtility = CMdaAudioPlayerUtility::NewL(*this);
 2.               QString filepath = QFileInfo( m_sound->fileName() ).absoluteFilePath();
 3.               filepath = QDir::toNativeSeparators(filepath);
 4.               m_playUtility->OpenFileL(qt_QString2TPtrC(filepath)));

Line 1 starts a Symbian leave handling block, which is good because it also uses a Symbian leave generating function.

Line 2 creates a QString, uses QFileInfo and various member functions. These could all throw exceptions, which is not good inside a TRAP block.

Line 3 is unclear as to whether it might throw an exception, but since it's dealing with strings it probably does, again bad.

Line 4 is tricky, it calls a leaving function which is ok within a TRAP, but it also uses a helper function to convert string types. In this case the helper function may cause an unwelcome exception.

We could rewrite this with nested exception translations, but it's much easier to refactor it.

 QString filepath = QFileInfo( m_sound->fileName() ).absoluteFilePath();
 filepath = QDir::toNativeSeparators(filepath);
 TPtrC filepathPtr(qt_QString2TPtrC(filepath));
 TRAPD(err, m_playUtility = CMdaAudioPlayerUtility::NewL(*this);

Now the exception generating functions are separated from the leaving functions.

Advanced technique

When using Symbian APIs in Qt code, you may find that Symbian leaving code and Qt exception throwing code are just too mixed up to have them interoperate through barriers. In some circumstances you can allow code to both leave and throw exceptions. But you must be aware of the following issues:

  • Depending on whether a leave or exception is thrown, or a normal exit happens, the cleanup order will vary. If the code leaves, cleanup stack cleanup will happen first. On an exception however, cleanup stack cleanup will happen last.
  • There must not be any destructor dependencies between different code styles. That is, you must not have symbian objects using Qt objects in their destructors, and vice versa. This is because the cleanup order varies, and may result in objects being used after they are deleted.
  • The cleanup stack must not refer to any stack based object. For instance, in Symbian you may use CleanupClosePushL() to push stack based R-classes onto the cleanup stack. However if the stack has unwound due to an exception before the cleanup stack cleanup happens, stack based objects will now be invalid. Instead of using the cleanup stack, consider Symbian's new LManagedHandle<> (or a custom cleanup object) to tie R-class cleanup to the stack.
  • Mixed throwing code must be called within both a TRAP and a try/catch harness. Standard exceptions must not propagate to the TRAP and cleanup stack cleanup will only happen if a leave is thrown, so the correct pattern is either TRAPD(err, QT_TRYCATCH_LEAVING( f )); or QT_TRAP_THROWING( QT_TRYCATCH_LEAVING( f ));, depending if you want an error code or exception as a result.

Best Of

Actualités les plus lues

  1. Microsoft ouvre aux autres compilateurs C++ AMP, la spécification pour la conception d'applications parallèles C++ utilisant le GPU 22
  2. Les développeurs ignorent-ils trop les failles découvertes dans leur code ? Prenez-vous en compte les remarques des autres ? 17
  3. RIM : « 13 % des développeurs ont gagné plus de 100 000 $ sur l'AppWord », Qt et open-source au menu du BlackBerry DevCon Europe 0
  4. « Quelque chose ne va vraiment pas avec les développeurs "modernes" », un développeur à "l'ancienne" critique la multiplication des bibliothèques 12
  5. 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
  6. Adieu qmake, bienvenue qbs : Qt Building Suite, un outil déclaratif et extensible pour la compilation de projets Qt 17
  7. Quelles nouveautés de C++11 Visual C++ doit-il rapidement intégrer ? Donnez-nous votre avis 10
Page suivante

Le Qt Developer Network au hasard


La création de colonnes dans une ListView en QML

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.



Liens utiles


  • 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 !

Hébergement Web