| 1 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
| 2 | %% Name: texcept.tex |
| 3 | %% Purpose: C++ exceptions and wxWidgets overview |
| 4 | %% Author: Vadim Zeitlin |
| 5 | %% Modified by: |
| 6 | %% Created: 17.09.03 |
| 7 | %% RCS-ID: $Id$ |
| 8 | %% Copyright: (c) 2003 Vadim Zeitlin |
| 9 | %% License: wxWindows license |
| 10 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
| 11 | |
| 12 | \section{C++ exceptions overview}\label{exceptionsoverview} |
| 13 | |
| 14 | \subsection{Introduction}\label{exceptionintroduction} |
| 15 | |
| 16 | wxWidgets had been started long before the exceptions were introduced in C++ so |
| 17 | it is not very surprising that it is not built around using them as some more |
| 18 | modern C++ libraries are. For instance, the library doesn't throw exceptions to |
| 19 | signal about the errors. Moreover, up to (and including) the version 2.4 of |
| 20 | wxWidgets, even using the exceptions in the user code was dangerous because the |
| 21 | library code wasn't exception-safe and so an exception propagating through it |
| 22 | could result in memory and/or resource leaks, and also not very convenient. |
| 23 | |
| 24 | Starting from the version 2.5.1 wxWidgets becomes more exception-friendly. It |
| 25 | still doesn't use the exceptions by itself but it should be now safe to use the |
| 26 | exceptions in the user code and the library tries to help you with this. Please |
| 27 | note that making the library exception-safe is still work in progress. |
| 28 | |
| 29 | |
| 30 | \subsection{Strategies for exceptions handling}\label{exceptionstrategies} |
| 31 | |
| 32 | There are several choice for using the exceptions in wxWidgets programs. First |
| 33 | of all, you may not use them at all. As stated above, the library doesn't throw |
| 34 | any exceptions by itself and so you don't have to worry about exceptions at all |
| 35 | unless your own code throws them. This is, of course, the simplest solution but |
| 36 | may be not the best one to deal with all possible errors. |
| 37 | |
| 38 | Another strategy is to use exceptions only to signal truly fatal errors. In |
| 39 | this case you probably don't expect to recover from them and the default |
| 40 | behaviour -- to simply terminate the program -- may be appropriate. If it is |
| 41 | not, you may override \helpref{OnUnhandledException()}{wxapponunhandledexception} |
| 42 | in your wxApp-derived class to perform any clean up tasks. Note, however, that |
| 43 | any information about the exact exception type is lost when this function is |
| 44 | called, so if you need you should override \helpref{OnRun()}{wxapponrun} and |
| 45 | add a try/catch clause around the call of the base class version. This would |
| 46 | allow you to catch any exceptions generated during the execution of the main |
| 47 | event loop. To deal with the exceptions which may arise during the program |
| 48 | startup and/or shutdown you should insert try/catch clauses in |
| 49 | \helpref{OnInit()}{wxapponinit} and/or \helpref{OnExit()}{wxapponexit} as well. |
| 50 | |
| 51 | Finally, you may also want to continue running even when certain exceptions |
| 52 | occur. If all of your exceptions may happen only in the event handlers of a |
| 53 | single class (or only in the classes derived from it), you may centralize your |
| 54 | exception handling code in \helpref{ProcessEvent}{wxevthandlerprocessevent} |
| 55 | method of this class. If this is impractical, you may also consider overriding |
| 56 | the \helpref{wxApp::HandleEvent()}{wxapphandleevent} which allows you to handle |
| 57 | all the exceptions thrown by any event handler. |
| 58 | |
| 59 | |
| 60 | \subsection{Technicalities}\label{exceptionstechnicalities} |
| 61 | |
| 62 | To use any kind of exception support in the library you need to build it with |
| 63 | \texttt{wxUSE\_EXCEPTIONS} set to $1$. This should be the case by default but |
| 64 | if it isn't, you should edit the \texttt{include/wx/msw/setup.h} file under |
| 65 | Windows or run \texttt{configure} with \texttt{--enable-exceptions} argument |
| 66 | under Unix. |
| 67 | |
| 68 | On the other hand, if you do \emph{not} plan to use exceptions, setting this |
| 69 | flag to $0$ or using \texttt{--disable-exceptions} could result in a leaner and |
| 70 | slightly faster library. |
| 71 | |
| 72 | As for any other library feature, there is a \helpref{sample}{sampleexcept} |
| 73 | showing how to use it. Please look at its sources for further information. |
| 74 | |
| 75 | |