Re: [Opensync-devel] Assertions are killing frontend GUI's

[Daniel G. <dg...@su...>]

On Tuesday 09 September 2008 23:06:14 Henrik /KaarPoSoft wrote:
> Hi all,
>
> A frontend GUI wants to stay alive, no matter what errors may be
> encountered in libraries it calls.
>
> An OpenSync frontend GUI may protect itself against signals and
> exceptions on the main thread.
> However, OpenSync are spawning new threads.
>
> Does anybody know a way a frontend GUI may protect itself against
> signals and exceptions on those threads?
>
> As an example, see https://sourceforge.net/forum/message.php?msg_id=5232971
> One user of my frontend GUI (http://bluezync.kaarposoft.dk/) users
> reports  that a problem in libsyncml kills Thunderbird (the frontend GUI).
>
> Is there any way a frontend GUI can protect itself against such errors?
> Or some way OpenSync may not just bail out, but present a nice error
> message to the GUI?
>
> Any thoughts on this would be much appreciated.

That's the purpose of assert(). We often are lazy instead of writing proper 
error handling we just place an assert(). Developers should of course only 
use assert() to hunt only very very unintended and complex error conditions. 
(Wrong API usage, unintended values in internal API, ...)

When shipping this to a regular user (maybe also tester?) you should make sure 
the build which got used is compiled with -DNDEBUG. So an assert() will not 
cause an expection:

--- man 3 assert ---
 DESCRIPTION
       If  the  macro  NDEBUG  was  defined  at the moment <assert.h> was last
       included, the macro assert() generates no code, and hence does  nothing
       at all.  Otherwise, the macro assert() prints an error message to stan‐
       dard error and terminates the program by calling abort(3) if expression
       is false (i.e., compares equal to zero).

       The  purpose  of  this macro is to help the programmer find bugs in his
       program.   The  message  "assertion  failed  in  file  foo.c,  function
       do_bar(), line 1287" is of no help at all to a user.
----

So, anything you find via assert() - report them! Make sure for "production" 
release (in CMake there is a default BuildType which is called 
RelWithDebInfo, which should also include -DNDEBUG) is build with -DNDEBUG.

Of course assert() which handle error conditions (OOM, wrong values from some 
device/protocol/user, ...) should be replaced by proper error handling.

best regards,
Daniel