-Another strategy is to use exceptions only to signal truly fatal errors. In
-this case you probably don't expect to recover from them and the default
-behaviour -- to simply terminate the program -- may be appropriate. If it is
-not, you may override wxApp::OnUnhandledException()
-in your wxApp-derived class to perform any clean up tasks. Note, however, that
-any information about the exact exception type is lost when this function is
-called, so if you need you should override wxApp::OnRun() and
-add a try/catch clause around the call of the base class version. This would
-allow you to catch any exceptions generated during the execution of the main
-event loop. To deal with the exceptions which may arise during the program
-startup and/or shutdown you should insert try/catch clauses in
-wxApp::OnInit() and/or wxApp::OnExit() as well.
-
-Finally, you may also want to continue running even when certain exceptions
-occur. If all of your exceptions may happen only in the event handlers of a
-single class (or only in the classes derived from it), you may centralize your
-exception handling code in wxApp::ProcessEvent
-method of this class. If this is impractical, you may also consider overriding
-the wxApp::HandleEvent() which allows you to handle
-all the exceptions thrown by any event handler.
+The next simplest strategy is to only use exceptions inside non-GUI code, i.e.
+never let unhandled exceptions escape the event handler in which it happened.
+In this case using exceptions in wxWidgets programs is not different from using
+them in any other C++ program.
+
+Things get more interesting if you decide to let (at least some) exceptions
+escape from the event handler in which they occurred. Such exceptions will be
+caught by wxWidgets and the special wxApp::OnExceptionInMainLoop() method will
+be called from the @c catch clause. This allows you to decide in a single place
+what to do about such exceptions: you may want to handle the exception somehow
+or terminate the program. In this sense, OnExceptionInMainLoop() is equivalent
+to putting a @c try/catch block around the entire @c main() function body in
+the traditional console programs. However notice that, as its name indicates,
+this method won't help you with the exceptions thrown before the main loop is
+started or after it is over, so you may still want to have @c try/catch in your
+overridden wxApp::OnInit() and wxApp::OnExit() methods too, otherwise
+wxApp::OnUnhandledException() will be called.
+
+Finally, notice that even if you decide to not let any exceptions escape in
+this way, this still may happen unexpectedly in a program using exceptions as a
+result of a bug. So consider always overriding OnExceptionInMainLoop() in your
+wxApp-derived class if you use exceptions in your program, whether you expect
+it to be called or not. In the latter case you may simple re-throw the
+exception and let it bubble up to OnUnhandledException() as well.
+
+To summarize, when you use exceptions in your code, you may handle them in the
+following places, in order of priority:
+ -# In a @c try/catch block inside an event handler.
+ -# In wxApp::OnExceptionInMainLoop().
+ -# In wxApp::OnUnhandledException().
+
+In the first two cases you may decide whether you want to handle the exception
+and continue execution or to exit the program. In the last one the program is
+about to exit already so you can just try to save any unsaved data and notify
+the user about the problem (while being careful not to throw any more
+exceptions as otherwise @c std::terminate() will be called).
projects / wxWidgets.git / blobdiff