--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/src/howtos/exceptionsafety.qdoc Thu Apr 08 14:19:33 2010 +0300
@@ -0,0 +1,156 @@
+/****************************************************************************
+**
+** Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies).
+** All rights reserved.
+** Contact: Nokia Corporation (qt-info@nokia.com)
+**
+** This file is part of the documentation of the Qt Toolkit.
+**
+** $QT_BEGIN_LICENSE:LGPL$
+** No Commercial Usage
+** This file contains pre-release code and may not be distributed.
+** You may use this file in accordance with the terms and conditions
+** contained in the Technology Preview License Agreement accompanying
+** this package.
+**
+** GNU Lesser General Public License Usage
+** Alternatively, this file may be used under the terms of the GNU Lesser
+** General Public License version 2.1 as published by the Free Software
+** Foundation and appearing in the file LICENSE.LGPL included in the
+** packaging of this file. Please review the following information to
+** ensure the GNU Lesser General Public License version 2.1 requirements
+** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
+**
+** In addition, as a special exception, Nokia gives you certain additional
+** rights. These rights are described in the Nokia Qt LGPL Exception
+** version 1.1, included in the file LGPL_EXCEPTION.txt in this package.
+**
+** If you have questions regarding the use of this file, please contact
+** Nokia at qt-info@nokia.com.
+**
+**
+**
+**
+**
+**
+**
+**
+** $QT_END_LICENSE$
+**
+****************************************************************************/
+
+/*!
+ \page exceptionsafety.html
+ \title Exception Safety
+ \ingroup best-practices
+ \brief A guide to exception safety in Qt.
+
+ \bold {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
+ \l QIODevice::errorString() or \l 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.
+
+ \tableofcontents
+
+ \section1 Exception safe modules
+
+ \section2 Containers
+
+ Qt's \l{container classes} are generally exception neutral. They pass any
+ exception that happens within their contained type \c T to the user
+ while keeping their internal state valid.
+
+ Example:
+
+ \code
+ QList<QString> list;
+ ...
+ try {
+ list.append("hello");
+ } catch (...) {
+ }
+ // list is safe to use - the exception did not affect it.
+ \endcode
+
+ 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:
+
+ \code
+ MyType s = list.takeAt(2);
+ \endcode
+
+ If an exception occurs during the assignment of \c s, the value at index 2 is already
+ removed from the container, but hasn't been assigned to \c s yet. It is lost
+ without chance of recovery.
+
+ The correct way to write it:
+
+ \code
+ MyType s = list.at(2);
+ list.removeAt(2);
+ \endcode
+
+ 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.
+
+ \section1 Out of Memory Handling
+
+ Most desktop operating systems overcommit memory. This means that \c malloc()
+ or \c{operator new} return a valid pointer, even though there is not enough
+ memory available at allocation time. On such systems, no exception of type
+ \c 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, \l QImage::create()
+ returns false if not enough memory exists instead of throwing an exception.
+
+ \section1 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:
+
+ \code
+ 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
+ }
+ \endcode
+
+ 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.
+
+ \section1 Platform-Specific Exception Handling
+
+ \section2 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 \l{Exception Safety with Symbian} document shows how to use the facilities provided
+ by Qt to use exceptions as safely as possible.
+*/