docs/doxygen/overviews/debugging.h

   1 /////////////////////////////////////////////////////////////////////////////
   2 // Name:        debugging.h
   3 // Purpose:     topic overview
   4 // Author:      Vadim Zeitlin
   5 // Copyright:   (c) 2009 Vadim Zeitlin <vadim@wxwidgets.org>
   6 // RCS-ID:      $Id$
   7 // Licence:     wxWindows licence
   8 /////////////////////////////////////////////////////////////////////////////
   9
  10 /**
  11
  12 @page overview_debugging Debugging
  13
  14 @tableofcontents
  15
  16 Various classes, functions and macros are provided in wxWidgets to help you
  17 debug your application. Assertion macros allow you to insert various checks in
  18 your application which can be compiled out or disabled in release builds but
  19 are extremely useful while developing. Logging functions are also provided
  20 which are useful for inserting traces into your application code as well as
  21 debugging. Both assertions and debug logging are also used by wxWidgets itself
  22 so you may encounter them even if you don't use either of these features
  23 yourself.
  24
  25 @see wxLog, @ref group_funcmacro_log, @ref group_funcmacro_debug
  26
  27
  28
  29 @section overview_debugging_config Configuring Debug Support
  30
  31 Starting with wxWidgets 2.9.1 debugging features are always available by
  32 default (and not only in a special "debug" build of the library) and you need
  33 to predefine wxDEBUG_LEVEL symbol as 0 when building both the library and your
  34 application to remove them completely from the generated object code. However
  35 the debugging features are disabled by default when the application itself is
  36 built with @c NDEBUG defined (i.e. in "release" or "production" mode) so there
  37 is no need to do this, unless the resources of the system your application will
  38 be running on are unusually constrained (notice that when asserts are disabled
  39 their condition is not even evaluated so the only run-time cost is a single
  40 condition check and the extra space taken by the asserts in the code).
  41
  42 This automatic deactivation of debugging code is done by IMPLEMENT_APP() macro
  43 so if you don't use you may need to explicitly call wxDISABLE_DEBUG_SUPPORT()
  44 yourself.
  45
  46 Also notice that it is possible to build your own application with a different
  47 value of wxDEBUG_LEVEL than the one which was used for wxWidgets itself. E.g.
  48 you may be using an official binary version of the library which will have been
  49 compiled with default @code wxDEBUG_LEVEL == 1 @endcode but still predefine
  50 wxDEBUG_LEVEL as 0 for your own code.
  51
  52 On the other hand, if you do want to keep the asserts even in production
  53 builds, you will probably want to override the handling of assertion failures
  54 as the default behaviour which pops up a message box notifying the user about
  55 the problem is usually inappropriate. Use wxSetAssertHandler() to set up your
  56 own custom function which should be called instead of the standard assertion
  57 failure handler. Such function could log an appropriate message in the
  58 application log file or maybe notify the user about the problem in some more
  59 user-friendly way.
  60
  61
  62
  63 @section overview_debugging_dbgmacros Assertion Macros
  64
  65 wxASSERT(), wxFAIL(), wxCHECK() as well as their other variants (see @ref
  66 group_funcmacro_debug) are similar to the standard assert() macro but are more
  67 flexible and powerful. The first of them is equivalent to assert() itself, i.e.
  68 it simply checks a condition and does nothing if it is true. The second one is
  69 equivalent to checking an always false condition and is supposed to be used for
  70 code paths which are supposed to be inaccessible (e.g. @c default branch of a
  71 @c switch statement which should never be executed). Finally, the wxCHECK()
  72 family of macros verifies the condition just as wxASSERT() does and performs
  73 some action such returning from the function if it fails -- thus, it is useful
  74 for checking the functions preconditions.
  75
  76 All of the above functions exist in @c _MSG variants which allow you to provide
  77 a custom message which will be shown (or, more generally, passed to the assert
  78 handler) if the assertion fails, in addition to the usual file and line number
  79 information and the condition itself.
  80
  81 Example of using an assertion macro:
  82 @code
  83 void GetTheAnswer(int *p)
  84 {
  85     wxCHECK_RET( p, "pointer can't be NULL in GetTheAnswer()" );
  86
  87     *p = 42;
  88 };
  89 @endcode
  90
  91 If the condition is false, i.e. @c p is @NULL, the assertion handler is called
  92 and, in any case (even when wxDEBUG_LEVEL is 0), the function returns without
  93 dereferencing the NULL pointer on the next line thus avoiding a crash.
  94
  95 The default assertion handler behaviour depends on whether the application
  96 using wxWidgets was compiled in release build (with @c NDEBUG defined) or debug
  97 one (without) but may be changed in either case as explained above. If it
  98 wasn't changed, then nothing will happen in the release build and a message box
  99 showing the information about the assert as well as allowing to stop the
 100 program, ignore future asserts or break into the debugger is shown. On the
 101 platforms where wxStackWalker is supported the message box will also show the
 102 stack trace at the moment when the assert failed often allowing you to diagnose
 103 the problem without using the debugger at all. You can see an example of such
 104 message box in the @ref page_samples_except.
 105
 106
 107
 108 @section overview_debugging_logging Logging Functions
 109
 110 You can use the wxLogDebug and wxLogTrace functions to output debugging
 111 information in debug mode; it will do nothing for non-debugging code.
 112
 113 */