]>
Commit | Line | Data |
---|---|---|
15b6757b | 1 | ///////////////////////////////////////////////////////////////////////////// |
3b88355f | 2 | // Name: exceptions.h |
15b6757b FM |
3 | // Purpose: topic overview |
4 | // Author: wxWidgets team | |
5 | // RCS-ID: $Id$ | |
526954c5 | 6 | // Licence: wxWindows licence |
15b6757b FM |
7 | ///////////////////////////////////////////////////////////////////////////// |
8 | ||
880efa2a | 9 | /** |
36c9828f | 10 | |
928f1a07 | 11 | @page overview_exceptions C++ Exceptions |
36c9828f | 12 | |
831e1028 | 13 | @tableofcontents |
36c9828f | 14 | |
928f1a07 FM |
15 | wxWidgets had been started long before the exceptions were introduced in C++ so |
16 | it is not very surprising that it is not built around using them as some more | |
17 | modern C++ libraries are. For instance, the library doesn't throw exceptions to | |
18 | signal about the errors. Moreover, up to (and including) the version 2.4 of | |
19 | wxWidgets, even using the exceptions in the user code was dangerous because the | |
20 | library code wasn't exception-safe and so an exception propagating through it | |
21 | could result in memory and/or resource leaks, and also not very convenient. | |
3b88355f | 22 | |
7dbd7137 VZ |
23 | However the recent wxWidgets versions are exception-friendly. This means that |
24 | while the library still doesn't use the exceptions by itself, it should be now | |
25 | safe to use the exceptions in the user code and the library tries to help you | |
26 | with this. | |
36c9828f FM |
27 | |
28 | ||
831e1028 BP |
29 | |
30 | @section overview_exceptions_strategies Strategies for Exception Handling | |
36c9828f | 31 | |
928f1a07 FM |
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. | |
3b88355f | 37 | |
7dbd7137 VZ |
38 | The next simplest strategy is to only use exceptions inside non-GUI code, i.e. |
39 | never let unhandled exceptions escape the event handler in which it happened. | |
40 | In this case using exceptions in wxWidgets programs is not different from using | |
41 | them in any other C++ program. | |
42 | ||
43 | Things get more interesting if you decide to let (at least some) exceptions | |
44 | escape from the event handler in which they occurred. Such exceptions will be | |
45 | caught by wxWidgets and the special wxApp::OnExceptionInMainLoop() method will | |
46 | be called from the @c catch clause. This allows you to decide in a single place | |
47 | what to do about such exceptions: you may want to handle the exception somehow | |
48 | or terminate the program. In this sense, OnExceptionInMainLoop() is equivalent | |
49 | to putting a @c try/catch block around the entire @c main() function body in | |
50 | the traditional console programs. However notice that, as its name indicates, | |
51 | this method won't help you with the exceptions thrown before the main loop is | |
52 | started or after it is over, so you may still want to have @c try/catch in your | |
53 | overridden wxApp::OnInit() and wxApp::OnExit() methods too, otherwise | |
54 | wxApp::OnUnhandledException() will be called. | |
55 | ||
56 | Finally, notice that even if you decide to not let any exceptions escape in | |
57 | this way, this still may happen unexpectedly in a program using exceptions as a | |
58 | result of a bug. So consider always overriding OnExceptionInMainLoop() in your | |
59 | wxApp-derived class if you use exceptions in your program, whether you expect | |
60 | it to be called or not. In the latter case you may simple re-throw the | |
61 | exception and let it bubble up to OnUnhandledException() as well. | |
62 | ||
63 | To summarize, when you use exceptions in your code, you may handle them in the | |
64 | following places, in order of priority: | |
65 | -# In a @c try/catch block inside an event handler. | |
66 | -# In wxApp::OnExceptionInMainLoop(). | |
67 | -# In wxApp::OnUnhandledException(). | |
68 | ||
69 | In the first two cases you may decide whether you want to handle the exception | |
70 | and continue execution or to exit the program. In the last one the program is | |
71 | about to exit already so you can just try to save any unsaved data and notify | |
72 | the user about the problem (while being careful not to throw any more | |
73 | exceptions as otherwise @c std::terminate() will be called). | |
36c9828f FM |
74 | |
75 | ||
928f1a07 | 76 | @section overview_exceptions_tech Technicalities |
36c9828f | 77 | |
928f1a07 | 78 | To use any kind of exception support in the library you need to build it |
7dbd7137 VZ |
79 | with @c wxUSE_EXCEPTIONS set to 1. It is turned on by default but you may |
80 | wish to check @c include/wx/msw/setup.h file under Windows or run @c configure | |
81 | with explicit @c --enable-exceptions argument under Unix. | |
3b88355f | 82 | |
928f1a07 FM |
83 | On the other hand, if you do not plan to use exceptions, setting this |
84 | flag to 0 or using @c --disable-exceptions could result in a leaner and | |
85 | slightly faster library. | |
36c9828f | 86 | |
928f1a07 FM |
87 | As for any other library feature, there is a sample (@c except) |
88 | showing how to use it. Please look at its sources for further information. | |
36c9828f | 89 | |
3b88355f | 90 | */ |