> -----Original Message----- > From: Olivier Goffart [mailto:oliv...@woboq.com] > Sent: 11 May 2012 12:53 > To: Kearns, Shane > Cc: lars.kn...@nokia.com; development@qt-project.org > Subject: Re: [Development] Enable Exceptions for Windows CE as default > > On Friday 11 May 2012 11:01:38 shane.kea...@accenture.com wrote: > > You would also need to disable exceptions in STL. > > MSVC will link exception and no exception code without a warning. > > > > Exception thrown from exception handling DLL or object file to non > > exception using main() results in a crash and call to terminate() > > > > Exception thrown through a non exception handling DLL or object file > > is caught, but with intermediate destructors not called. > > > > i.e. with this proposal, if application code calls a Qt function > > inside a try block, and throws an exception from application code > > callback or plugin code, it may silently fail by catching the > > exception but the intermediate stack objects of the Qt code not > having been cleaned up. > > That is assuming those Qt functions as exceptions safe. But we don't > really offer such garentee anywere except in few QtCore classes. Most > of the code is not exception safe and will leak or produce undefined > behaviour in case of exceptions. > > Exceptions are not supposed to cross the Qt layers. (Unless explicitly > documented as working) > > Regarding the STL, the only sensible exception that might be thrown by > the STL is std::bad_alloc (The other ones are not supposed to happen). > And handling OOM error is IMHO pointless in a gui application (too > difficult, unstested, unreliable, don't get me started on this...) >
I'm talking about Qt compiled without exception handling in MSVC ( CL /Eh-c- compiler option) Although I only tested this with 3 functions compiled as separate libraries. main() calls bar() which calls foo() main() and foo() are compiled with exception support bar() is compiled without exception support If main() has a try block and foo() throws an exception main() catches the exception stack objects from main() and foo() are cleaned up stack objects from bar() are leaked Mingw32 4.6.2 (which seems to use setjmp/longjmp for exception handling) behaves the same as MSVC2010 (which uses windows SEH) Now another compiler could choose to call terminate() here instead (detecting exception has passed through code without exception handling). Or just crash - it's undefined behaviour. When all the libraries are compiled with exceptions enabled, the behaviour is defined by the language - although any given code path may not be exception safe due to the program. The ARM ABI for exceptions includes an exception handling table as part of the ELF file. RVCT4.0 does not produce linker warnings for mixing exception & no exception code, but I don't know the behaviour at run time. -- ________________________________ Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. ______________________________________________________________________________________ www.accenture.com _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
