Felsök med brytpunkter och watches i Rider
↑En debugger låter dig pausa körningen och undersöka tillståndet runt ett problem. Skriv först ned hur felet återskapas och vilket värde du förväntar dig. Då slipper du stega planlöst genom ett stort projekt.
En tydlig felsökningsrutin
Section titled “En tydlig felsökningsrutin”- Starta rätt run/debug-konfiguration och sätt en brytpunkt nära misstänkt metod.
- Återskapa felet. Om brytpunkten inte träffas, kontrollera symboler, konfiguration och att kodvägen verkligen körs.
- Undersök lokala variabler och watches. Var datan fel redan före metoden eller ändras den inne i metoden?
- Step over kör nästa sats utan att gå in i anropet. Step into går in i anropet och step out återvänder till anroparen.
- Dokumentera felet i ett regressionstest när det är möjligt och ta bort tillfälliga debugändringar.
Villkorliga brytpunkter
Section titled “Villkorliga brytpunkter”En villkorlig brytpunkt kan pausa enbart när ett visst värde används, till exempel ett bestämt spelar-ID. Undvik villkor som ändrar applikationens tillstånd. Beteendet beror på runtime och om Rider är anslutet till .NET eller Unity.
Vid Unity-debuggning måste Rider ansluta till rätt Editor- eller player-process. Kontrollera att projektet och symbolerna hör till den körande versionen. Pauser kan påverka tidsberoende gameplay och fysikuppdateringar.
Övning: Hitta varför en räknare plötsligt nollställs. Studera anropsstacken innan du ändrar kod och skriv sedan ett test för lösningen.
Referenser: Rider debugger och Rider navigation.