2011-01-13 15 views

risposta

5

No. Ma è possibile avere punti di interruzione condizionali. Immagino che colpire l'altro punto di interruzione indichi qualche cambiamento di stato.

Quindi, Right click the breakpoint -> Breakpoint properties -> check "conditional"

0

Se si conosce la condizione in cui verrà colpito l'altro punto di rottura, allora si può aggiungere che la condizione per il nuovo punto di interruzione.

0

I punti di interruzione condizionali sono una possibilità e puoi anche impostare un conteggio degli hit in modo che il punto di interruzione venga attivato solo dopo essere stato colpito il numero specificato di volte.

Ma no, non c'è modo di fare quello che stai chiedendo.

0

Un'altra idea è disattivare il punto di interruzione e attivarlo una volta raggiunto l'altro punto di interruzione.

+0

Sì, questo è quello che faccio adesso, ma è un dolore continuare a farlo. – Kyle

6

Questo è un grande hack, ma è una soluzione funzionale:

chiamata la 'trigger' posizione punto di interruzione 1 e la posizione di destinazione punto di interruzione 2. Vogliamo Punto di arresto 2 al fuoco se-e-solo-se l'esecuzione ha superato il punto di interruzione 1.

Impostare i punti di interruzione condizionali su ciascuno.

Per il punto di interruzione 1, impostare la condizione come System.setProperty("breaknow", "breaknow") == "". Questa condizione non sarà mai vera, ma verrà impostata una proprietà di sistema che possiamo leggere al punto di interruzione 2.

Per il punto di interruzione 2, impostare la condizione come System.clearProperty("breaknow") != null. Questa condizione si innesca quando viene impostata la proprietà di sistema e la cancella (quindi possiamo ripetere se necessario).

Come ho detto, è un trucco, ma sembra funzionare. Ho inviato una richiesta di miglioramento di Eclipse per implementare il collegamento o concatenare i punti di interruzione come funzionalità nativa (https://bugs.eclipse.org/bugs/show_bug.cgi?id=390590). Sfortunatamente, non ho la larghezza di banda per implementarlo da solo, ma forse un giorno avremo il supporto per una soluzione più pulita.

Un avvertimento (che si applica a tutti i punti di interruzione condizionali, non solo a questo trucco): Dalla mia esperienza, sembra che un'impostazione di un punto di interruzione condizionale impedisca al JIT di compilare il metodo di interesse, eseguendolo invece in modalità interpretata. O forse, consente il primo stage C1 JIT ma impedisce al compilatore C2 di secondo stadio di ottimizzare?

In entrambi i casi, è necessario tenere presente che il metodo di cui si sta eseguendo il debug verrà eseguito molto più lentamente con un punto di interruzione condizionale in atto. Questo di solito non è un problema, ma quando eseguo il debug di loop interni molto stretti, ho trovato che è meglio ricorrere al metodo (sciatto) if (x) { // Do somthing useless and set a breakpoint here}.

Problemi correlati