2011-11-14 7 views
17

Spesso mi trovo a impostare un punto di interruzione A da qualche parte nel codice e abilitare manualmente uno o più punti di interruzione quando viene colpito questo punto di interruzione. Un caso tipico è quando eseguo il debug di un unittest e non mi preoccupo dei test precedenti.Abilita punto di interruzione B se il punto di interruzione A è stato colpito

void testAddZeros() 
{ 
    Number a(0); 
    Number b(0); 
    Number result = a.add(b); 
    assert((a + b) == Number(0)) 
} 
void testAddOnes() 
{ 
    Number a(1); 
    Number b(1); 
    Number result = a.add(b); 
    assert((a + b) == Number(2)); 
} 
void testAddNegativeNumber() 
{ 
    Number a(1); 
    Number b(-1) 
    Number result = a.add(b); 
    assert((a + b) == Number(0)); 
} 

immaginate se testAddZeros() e testAddOnes() corre bene, ma testAddNegativeNumber(). In questo caso, impostare un punto di interruzione su Number result = a.add(b); sarebbe un punto naturale per avviare il debug. Ora immagina che l'errore si trovi in ​​qualche punto profondo all'interno di Number::add, quindi non siamo realmente interrotti nelle cose che si verificano all'inizio di Numbers::add. Quello che voglio fare è impostare un breakpoint da qualche parte all'interno di Numbers::add che si innesca solo se sono all'interno del test testAddNegativeNumber().

C'è un modo per abilitare automaticamente il punto di interruzione B quando viene raggiunto il punto di interruzione A?

+1

Hai controllato i punti di interruzione condizionali? Probabilmente potresti usare la condizione su cui il punto di interruzione A viene colpito per abilitare il punto di interruzione "condizionale" B. (In tal caso, non hai più bisogno di breakpoint A) – ChristiaanV

+0

@ChristiaanV: sì, ma temo che i punti di interruzione condizionale non è sufficiente in questo caso, almeno non in generale. – larsmoa

+0

Puoi mostrare un esempio di codice, dove vorresti usare questo? – ChristiaanV

risposta

19

È possibile ottenere i punti di interruzione dipendenti anche senza modificare il codice, utilizzando una memoria globale per contenere il marcatore che consentirà il punto di interruzione dipendente.

Uno degli archivi più accessibili che ho trovato sono proprietà personalizzate del dominio app. Sono accessibili dai metodi System.AppDomain.CurrentDomain.GetData e SetData.

Così il primo punto di interruzione si definisce un "quando viene colpito" impostazione con:

{System.AppDomain.CurrentDomain.SetData ("rottura", true)}

breakpoint condition

Sul punto di interruzione dipendente, impostare la condizione di attivazione su:

System.AppDomain.Current Domain.GetData ("break")! = Null

+0

Mi chiedevo se questo genere di cose avrebbe funzionato con i tracepoints ... ora lo so. Upvoted! – codekaizen

2

Questa è una delle migliori Penso che si potrebbe fare, ma sembra troppo grande di un trucco per provare ancora, perché si tratta di aggiungere una variabile ...

string breakpointToStopOn = string.Empty; 
Console.WriteLine("HERE"); // You can set breakpoint A here, 
          // with a condition (right click on the breakpoint, then selectCondition), 
          // that sets breakpointToStopOn = "A" 
Console.WriteLine("B"); // and you can set your breakpoint here with this condition 
         // (breakpointToStopOn == "A"); 

Non sarà effettivamente in grado per fermarsi sulla riga Console.WriteLine ("QUI"), ma è possibile abilitare o disabilitare il punto di interruzione, che in effetti consentirebbe l'altro punto di interruzione.

Attenzione però, le dichiarazioni di breakpoint condizionale peggioreranno seriamente le prestazioni della tua app durante il debug.

+0

Anche se non è quello che stavo cercando, immagino che questo sia il migliore (ben, solo) suggerimento. – larsmoa