Complete.Org: Mailing Lists: Archives: freeciv-dev: September 2002:
[Freeciv-Dev] Re: concerning the use of assert
Home

[Freeciv-Dev] Re: concerning the use of assert

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: "Per I. Mathisen" <per@xxxxxxxxxxx>
Cc: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: concerning the use of assert
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Fri, 06 Sep 2002 13:07:46 -0400

At 12:57 PM 02/09/01 +0000, Per I. Mathisen wrote:
>I've had a little discussion with Ross about the use of asserts. While I
>enjoy using them liberally myself, I can see his point about making the
>game a minefield of potential cores that can often be avoided when we can
>instead return to a sane state.

Also, useless asserts that never get executed because they follow the 
first use or have the same effect as the line of code they are supposedly 
protecting. 

Asserts should flag meaningful program invariant conditions, and not 
just be redundant null pointer traps (null pointer generates a cleaner
core file than an assert anyway :-).

>The problem with doing such error recovery instead of an assert is that
>with an assert we get error reporting, with the former the error goes
>unreported.
>
>There should be a way to get the best of both worlds.

Asserts don't do error reporting, so you still need to do something to
list the state even if you saved it and not all users are going to pass
on the saved state, especially in such a non user friendly form. 

The missing error reporting is the key point which I think you are 
addressing below. Making this as complete as is reasonable and as simple 
to email in or bugreport is a good thing, as well as not antagonizing 
the user or detracting from playability (or usability in the case of 
developers) of the game.

>How about a function which can be called instead of assert, and which
>writes a bug report to file then creates a savegame to match, and finally
>notifies the player that a bug was detected and that he/she should send
>the bug report in to us. Maybe we could even launch gdb on ourself to get
>a backtrace on some platforms. Then do error recovery as best as we can.
>
>The interface could be something like
>
>       bool error(condition)
>
>which returns (!condition), so that we can do
>
>       if (error(punit == NULL || pdefender == NULL)) {
>               /* error recovery */
>               return;
>       }
>
>and then on some commandline switch becomes an assert(FALSE) instead for
>debugging.
>
>Though maybe the create-savegame part should be separate from the error()
>call, since we may not always be in a position to create a sane
>savegame...
>
>Other ideas?

The new function should be clearly stated as having the same interface 
as assert, thus you could switch to asserts (for the unconvinced) with 
a simple macro definition in a toplevel header file, or equivalently use 
an assert in the error function as one of its optional modes.

It should be possible to swipe the backtrace code and perhaps even dump
locals from gdb, though forking gdb commands and printing their output
is not an unreasonable quick fix. One can always print the locals under
program control as part of the code, though.

Every language should have an exception/backtrace facility as a set of
library functions, but perhaps this is a good reason to look for a new
programming language for Freeciv 2.0 instead of developing one for "C" 
when that time arrives :-).

Or maybe there is another program somewhere that had this problem and
has already produced a ready-made solution.

>Yours
>Per

Cheers,
RossW
=====




[Prev in Thread] Current Thread [Next in Thread]