Assicurarsi che la configurazione di caricamento (non predefinita) sia valida

Per proteggersi dall'immissione di dati inutili, è necessario convalidare l'input mentre l'utente lo inserisce. Nella stragrande maggioranza dei casi, il tuo input spazzatura non sarà così male come "paoghsfodgvfnamox33" per una com-port, ma una digitazione piuttosto maldestra, come "\ ttys \ comn2". Se rilevi questi errori il prima possibile, mentre l'utente sta ancora modificando la configurazione, l'utente può immediatamente correggere l'errore.

Per quanto riguarda il database che viene modificato all'esterno dell'applicazione, ci sono due linee di pensiero qui:

1. L'utente non dovrebbe accedere / modificare direttamente il database. Se lo fanno comunque, hanno rotto il sigillo di garanzia del prodotto (in senso figurato) e sono loro stessi responsabili delle conseguenze.
   Se segui questa linea, tuttavia, non ha senso convalidare la configurazione più di quanto non faccia attualmente, poiché i test hanno dimostrato che i metodi approvati di modifica della configurazione non possono corromperlo.
2. L'utente è autorizzato a fare tutto ciò che vuole con il database e dobbiamo essere robusti contro di esso.
   Se segui questa linea di pensiero, dovresti adottare misure aggiuntive contro valori di configurazione errati. Questo può essere semplice come provare prima il valore letto dal database e se questo non funziona, ricadere su un valore predefinito hardcoded.
   Oppure puoi aggiungere una colonna checksum alla tabella del database con i valori di configurazione. In questo modo puoi immediatamente rilevare che un valore di configurazione è cambiato fuori dal tuo controllo.

In generale, si può scrivere un checksum con i dati che possono essere ricalcolati al momento della lettura e confrontati con quelli scritti valore. Se non corrispondono, sai che c'è stato un danneggiamento dei dati (o che il tuo checksum è scaduto).

Potresti fare un ulteriore passo avanti e fornire sufficienti informazioni ridondanti per riparare la corruzione ( codici di correzione degli errori ), ma questo potrebbe essere eccessivo nel tuo caso.

Dato che stai usando un database (SQLite), generalmente fornisce i propri checksum e validazione dell'integrità dei dati internamente . Tuttavia, penso che sia improbabile leggere una stringa da esso e vedere dati confusi, come nel tuo esempio. In genere, se un file di database viene danneggiato, anche le informazioni strutturali nel file su cui si basa il database stesso sono danneggiate, quindi il database genererà (nel migliore dei casi) un errore o (nel peggiore dei casi) un arresto anomalo.