Come affrontare gli errori di sintassi durante lo sviluppo di un analizzatore lessicale?

Question

Come affrontare gli errori di sintassi durante lo sviluppo di un analizzatore lessicale?

#1 da (1 voti)

4

Sto scrivendo un linguaggio specifico del dominio interpretato per la mia applicazione. Ogni istruzione viene analizzata ed eseguita non appena l'analizzatore lessicale decide che viene raggiunta la fine dell'istruzione. Gestisce un token alla volta e fa chiamate ricorsive per valutare le espressioni e ridurre lo stack di token corrente.

È intuitivo che il parser verifichi innanzitutto gli errori di sintassi prima di interpretare ed eseguire effettivamente il codice, ma stavo pensando che potrebbe essere un altro modo di gestirlo.

Cosa succede se la sintassi è stata verificata appena prima che il codice in questione debba essere eseguito? Ciò significa che in realtà il flag di codice per la sintassi non valida non si verificherà fino a quando non verrà effettivamente raggiunto il codice problematico. Questo significa anche che se il codice è difettoso, ma non dovrebbe essere eseguito, possiamo generare avvisi non fatali invece di errori per notificare il programmatore, ma lasciare che il codice venga eseguito comunque.

Prendi ad esempio questo codice:

 1. new $a = 2
 2. new $b = 3
 3.
 4. while ($a < 10) {
 5.     $a += 3
 6.     $b += 2
 7.
 8.     if ($b < 5) {
 9.         $b = 
10.     }
11. }
12.
13. printout($a)
14. printout($b)

Mentre una riga viene digitata dopo l'altra, l'interprete standard eseguirà le prime due righe, ma l'errore verrebbe generato sulla riga 9, poiché nessun valore viene assegnato a $b e il processo terminerà a causa di un errore fatale.

Questo approccio emette:

SyntaxError at line 9: $b = ; - Expression expected
Process terminated with exit code 1

Se il parser verifica la sintassi di una riga alla volta, espressione $b < 5 non valuta mai true e il codice errato non viene mai eseguito. La sua sintassi è ancora controllata e genera un flag di avviso.

Questo approccio emette:

SyntaxWarning at line 9: $b = ; - Expression expected
SyntaxWarning at line 9: $b = ; - Expression expected
SyntaxWarning at line 9: $b = ; - Expression expected
11
9

Se il codice difettoso deve essere eseguito, SyntaxErrors verrà generato in modo incondizionato. L'unica differenza sarebbe quando il codice non viene eseguito. La lingua è scritta per la generazione di grafica / software di manipolazione.

Devo includere gli avvertimenti sulla sintassi nel mio interprete o devo lasciare che il codice difettoso termini sempre l'esecuzione? Quali fattori dovrebbero influenzare questa decisione?

error-handling syntax interpreters parsing

posta Mirac7 13.11.2015 - 16:15

fonte

1 risposta

Leggi altre domande sui tag error-handling syntax interpreters parsing

Ereditarietà quando si segue il modello di repository in PHP Architettura disaccoppiata in Android

score 1 · Answer 1

C'è davvero un solo fattore da considerare, che è quanto è sicuro che il tuo programma sia ABEND o produca incompleto o risultati non validi.

Un'estremità dello spettro è che è solo un fastidio. Le persone eseguono i loro programmi e scoprono che non hanno ottenuto i risultati che si aspettavano e quindi devono rintracciare la causa, forse dovendo scavare attraverso megabyte di dati che contengono un messaggio di errore di sintassi. Non c'è alcun danno reale, ma potrebbe rappresentare un problema di sicurezza personale se i tuoi utenti sono psicotici e conoscono il tuo indirizzo di casa. : -)

L'altro è che causa un danno reale, che è dove vuoi prendere un approccio tutto o niente. Se il dominio per la tua lingua coinvolge un processo di produzione di sostanze chimiche in cui il prodotto finito è inerte ma uno dei prodotti intermedi è tossico, un ABEND nel punto sbagliato potrebbe lasciare una vasca di fanghi tossici da trattare. In un caso del genere, vuoi essere il più sicuro possibile che il programma abbia una buona possibilità di finire prima di iniziare a farlo.

Fare l'una o l'altra non dovrebbe avere un impatto enorme sul tuo sviluppo. Un parser che produce un albero di analisi può semplicemente restituire qualche indicazione che si è verificato un errore, che rende la decisione di procedere o smettere facilmente. Quelli che eseguono le istruzioni così come li trovano avrebbero bisogno di un interruttore per impedirlo. Per impedire l'esecuzione di un programma non valido, dovrai analizzarlo due volte: una volta con l'esecuzione disabilitata e, se il parser non ha lamentato l'input, di nuovo con esso abilitato.

Il mio personale proposito è che se puoi fornire un modo per le persone che usano la tua lingua per convalidare i loro programmi senza eseguirli, dovresti farlo. Manipolare la grafica non è cruciale per la sicurezza, ma le persone che devono costruire e integrare sistemi usando la tua lingua vorranno farlo. Il processo di passaggio dallo sviluppo alla produzione è sempre più automatizzato e fornire un modo programmatico per lanciare un blocco stradale quando c'è un problema rilevabile è nient'altro che positivo.