Analisi del flusso di dati con eccezioni

L'analisi del flusso di dati funziona su un grafico del flusso di controllo. Quando una lingua in esame supporta le eccezioni, il grafico del flusso di controllo può esplodere.

Quali sono le tecniche standard per affrontare questa esplosione? Possiamo ignorare profondamente i bordi indotti dall'eccezione? Le analisi del flusso di dati calcolano comunque approssimazioni eccessive, quindi si finirebbe con una soluzione meno precisa ma solida. È vero?

Aggiornamento : ecco alcuni link utili che sono stato in grado di scavare alla fine:

programming-languages program-optimization software-verification

— bellpeace
fonte

Cosa intendi con "esplodere"? Sappiamo staticamente quali eccezioni possono essere lanciate dove? Quale tipo di aumento delle dimensioni saresti disposto ad accettare?

— Raffaello

Per esplosione intendo che il numero di blocchi di base viene aumentato e il numero di spigoli che li collegano, determinando tempi di esecuzione dell'analisi potenzialmente più elevati. La mia ipotesi, forse sbagliata, era che questo potrebbe essere un problema nei compilatori e forse ci sono dei modi per affrontarlo. Sono interessato a capire l'argomento.

— Bellpeace,

Ignorare le eccezioni non è corretto. Esempio:

let g = {
     raise E;
}
let f = {
     x := interesting_stuff();
     g();
     x := 0;
}

Durante l'analisi f, è necessario tenere conto del fatto che ggenera un'eccezione, altrimenti si concluderebbe erroneamente che xè sempre 0 al ritorno da f.

Non so che esiste una tecnica "standard" per gestire le eccezioni. C'è un po 'di letteratura sull'argomento, non ho più idea di quali documenti siano rilevanti rispetto a quelli che posso trovare da una ricerca su Google.

Formalmente, le eccezioni possono essere trasformate in istruzioni condizionali che si propagano nella catena di chiamate, che ovviamente fa saltare il grafico del flusso di controllo. In molti casi concreti, il caso di eccezione è il caso meno interessante, in cui molti dati vengono uccisi, quindi dovrebbero essere gestiti pigramente in un approccio avanzato (non è necessario analizzare la vivacità sul percorso dell'eccezione se il gestore uccide i dati) .

— Gilles 'SO- smetti di essere malvagio'
fonte

Una domanda di follow-up, se non ti dispiace. In sostanza, se mi mancano alcuni bordi, posso ottenere un risultato non corretto. Cosa succede se ho un flusso di controllo della codifica dei bordi che in realtà non è esposto durante l'esecuzione del programma? Avrei un risultato sonoro, ma potenzialmente meno preciso?

— Bellpeace,

@bellpeace Se un bordo corrisponde a un percorso che non viene mai intrapreso durante l'esecuzione, è un codice morto, quindi può essere rimosso senza influire sulla solidità. Il risultato sarebbe più preciso: hai una migliore approssimazione del programma, così puoi ottenere una migliore approssimazione del suo comportamento.

— Gilles 'SO- smetti di essere malvagio' il

Quindi, in sostanza, l'aggiunta di bordi aggiuntivi non influirà sulla solidità ma solo sulla precisione?

— Bellpeace,

@bellpeace Sì: se aggiungi potenziali percorsi, potresti introdurre nuovi potenziali flussi che non possono effettivamente verificarsi, ma non cancellerai tutti i flussi che si verificano.

— Gilles 'SO- smetti di essere malvagio' il

Aspetta, in questo esempio, x è sempre zero al ritorno da f. Se g genera un'eccezione, f non ritorna. Ora, se f ha colto l'eccezione (e forse riprogrammato), sarebbe una questione diversa, ma sarebbe un limite esplicito nel diagramma di flusso.

— Pseudonimo,