Dove è appropriato effettuare la convalida dell'input in Erlang?

7

Sto scrivendo un modulo che esegue una macchina a stati finiti * basata sul contenuto di una matrice di record passati all'inizializzazione. Ogni record descrive uno stato e include istruzioni su come agire sugli input (ad esempio, quando in stato S1 , l'input I attiva una transizione allo stato S2 ). Perché l'FSM funzioni correttamente, gli stati con transizione devono esistere.

Il mio dilemma è dove convalidare quelle transizioni.

Il programmatore difensivo in me dice di farlo una volta il prima possibile, come quando l'FSM è inizializzato. Ciò significa che posso generare un errore quando vengono dati per la prima volta dati fasulli ed evitare di restituire un processo che potrebbe fallire in un secondo momento. Il resto dell'attuazione non dovrà essere così difensivo perché la tabella è nota per essere valida e qualsiasi errore che Erlang decide di sollevare sarà un risultato dell'implementazione piuttosto che essere alimentato con dati errati. Faciliterà anche il debugging per chi usa il modulo poiché otterrà immediatamente un badarg o qualcos'altro, invece di dover passare in rassegna le mie fonti in seguito per capire che si trattava del loro errore e non mio.

La filosofia di Erlang sembra essere che le cose dovrebbero essere lasciate correre il più a lungo possibile, fallendo solo quando devono e lasciando che un supervisore si occupi di raccogliere i pezzi. Da un lato, questo ha senso perché un dato FSM potrebbe funzionare per sempre senza incontrare gli input che ci vorrebbe per una brutta transizione. Dall'altra parte, se non si fa tardi, si impone ai chiamanti di scrivere test ripetitivi per qualcosa che per me è facile da implementare una volta.

So che la maggior parte delle regole in questo settore non sono difficili e veloci, ma un approccio più "Erlangy" rispetto all'altro? Un'implementazione fallita potrebbe apparire fuori luogo se rilasciata per essere utilizzata da altri?

* Sono a conoscenza del comportamento di gen_fsm e quello che sto facendo ha alcune carenze comparative. Questo è un esercizio di apprendimento per alcune altre cose e un FSM sembra essere qualcosa che li incorpora.

    
posta Blrfl 18.05.2013 - 20:20
fonte

2 risposte

1

Il motivo per cui sembra meno "Erlangy" fare controlli di tipo onerosi è perché la lingua è tipizzata dinamicamente.

Se è davvero necessario assicurarsi che i dati di un determinato tipo vengano utilizzati, è possibile utilizzare le funzioni is_TYPE / 1 per verificare il proprio input come espressioni di guardia. Dovresti farlo il più presto possibile.

link

    
risposta data 23.07.2013 - 17:46
fonte
0

Il detto di Joe. Fallisci velocemente, fallisci rumorosamente, fallisci educatamente.

Sì, controlla i tuoi dati. Controlla ogni affermazione che puoi. Quindi il modello corrisponde a tutte le chiamate che puoi. Se ti aspetti una risposta ok da foo, scrivi:

 ok = foo()

anziché:

foo()

Usa le guardie per riprovare quando puoi.

In realtà, è possibile scrivere codice scadente in qualsiasi lingua.

    
risposta data 02.04.2016 - 07:26
fonte

Leggi altre domande sui tag