Effektiv Debuggen

[Neutral General]

Hi,

Ich bin grad an einem Doppelkopfspiel am programmieren und es klappt auch fast.. nur manchmal gibt es eine AV wenn die KI eine Karte legen soll.. Das kommt daher das eine Funktion der KI ne Nil-Karte zurückgegeben hat was normalerweise nicht sein kann.. aber da es anscheinend doch passiert. Oder irgendwas anderes. Dummerweise ist meine KI seeeehr umfangreich und um zu entscheiden welche Karte die KI legt brauche ich ca 30 verschiedene Funktionen + eine Hauptfunktion :pale:

Ich hab zwar schon einiges durch Breakpoints verbessern können aber das geht einfach nicht mehr...
Wenn ich an einer Stelle en Breakpoint hinsetze wo es ungefähr krachen könnte dann ist das Problem das normalerweise bei jeder Karte die ein Computerspieler spielt an dem Breakpoint angehalten wird. Und dadurch muss ich mich dann bei JEDER Karte durch die massig vielen und eventuell auch großen Funktionen mit vielen Schleifen durchdebuggen und meisten krachts erst gegen Ende des Spiels... Mh.. jeder Spieler hat 12 Karten.. 3 PC Spieler = 36 Karten = 36 * 30 Funktionen mit jeweils riesigen Schleifen. Da sitze ich noch nächstes Jahr dran :(

Kann der Debugger nicht irgendwie zu dem Punkt springen bei dems gekracht hat ? :|
Wenn ich Delphi-Exceptions an mache dann bekomm ich immer nur den Projekt Quelltext zu sehn nach der AV und davon hab ich auch nix...

Gruß
Neutral General

[Khabarakh]

Zitat:

Zitat von Neutral General

Kann der Debugger nicht irgendwie zu dem Punkt springen bei dems gekracht hat ? :|
Wenn ich Delphi-Exceptions an mache dann bekomm ich immer nur den Projekt Quelltext zu sehn nach der AV und davon hab ich auch nix...

Keinen Callstack, nix? Das ist natürlich schlecht :| .
Wäre es noch zu verkraften, in jede Funktion (vielleicht kannst du die Kandidaten ja noch eingrenzen)

Delphi-Quellcode:

Assert(FooKarte <> nil);

einzubauen?

[negaH]

Als aller erstes Assertion in deine Funktionen reinbauen. Mit zb.

Delphi-Quellcode:

begin
  Assert(Karte <> nil, 'Karten object in Funktion XYZ darf nicht nil sein').
end;

Diese Assertition kannst du per Compileroptionen Ein/Aus schalten und sind somit in deiner fertigen Anwendung nicht reincompiliert. Du kannst sie also im Source belassen und steuerst nur per Switches ob sie aktiv sind oder nicht.

Diese Vorgehensweise halte ich für den Anfang als weit effektiver als mit dem Debugger an falscher Stelle tausende von Sourcezeilen zu tracen.

Gruß Hagen

[Neutral General]

Naja ich hab schon in jede Funktion die es sein könnte

if Temp = -1 then ShowMessage('Fehler in Funktion xyz');

Denn in diesen Funktionen gibt die Funktion nil zurück wenn Temp = -1.. dh es muss an irgendwas anderem liegen :(

[Neutral General]

Hat keiner sonst noch irgendwelche Ideen ? Ich verzweifle noch dran :|

Sind zwar keine 24 Stunden aber es ist dringend :| :duck:

[DGL-luke]

Assertions scheinen mir das sicherste. Du kannst auch bei Karte = nil deinen eigenen "Breakpoint" setzen:

Delphi-Quellcode:

if Karte=nil then
  raise Exception.Create('Alarm!');

Aber Assertions machen auch nixhts anderes. WO liegt also im Moment dein Problem?

[Neutral General]

Zitat:

Zitat von DGL-luke

Assertions scheinen mir das sicherste. Du kannst auch bei Karte = nil deinen eigenen "Breakpoint" setzen:

Delphi-Quellcode:

if Karte=nil then
  raise Exception.Create('Alarm!');

Aber Assertions machen auch nixhts anderes. WO liegt also im Moment dein Problem?

Mein Problem hat sich vor 5 Minuten in Luft aufgelöst :) :)
Ich habe mir mal alle Karten von allen Spielern anzeigen lassen und nach langer Beobachtung hab ich dann herausgefunden das die AV immer dann kommt wenn Trumpf gespielt ist und der PC nach ner höheren Karte suchen soll aber wenn sie keine höhere hat dann wusste der PC nicht was er legen sollte und dann hats gekracht.. hab das jetzt behoben :)

Thx trotzdem für eure Hilfe ;)

Gruß
Neutral General