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

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Fri, Sep 06, 2002 at 01:07:46PM -0400, Ross W. Wetmore wrote:
> 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 :-).

I agree.

> >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.

As I said: you can call gdb from the calling wrapper script.

> 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.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Only one human captain has ever survived battle with the Minbari
  fleet. He is behind me. You are in front of me. If you value your 
  lives, be somewhere else."
    -- Ambassador Delenn, "Severed Dreams," Babylon 5