Come si gestisce un file di risorse errato?

Qual è la differenza tra un "errore catastrofico durante l'analisi" e un "fallimento dislessico" (diciamo un , invece di un ; , o un ' invece di un " - quelle due coppie di simboli sono sui tasti adiacenti sulla mia tastiera), fondamentalmente, dal punto di vista ^* dell'utente?

Se il JSON ^** non è corretto a causa di un refuso, dare un buon messaggio di errore non è di solito banale perché dal punto di vista parser , il ( errore catastrofico) potrebbe non essere il punto in cui l'errore effettivo proviene da un punto di vista umano . Quindi, a mio parere, il caso che stai "licenziando" come un dettaglio tecnico è difficile da affrontare.

Se hai un file JSON valido, ma le proprietà mancanti (o estranee), dare un buon messaggio di errore (cioè fallire nel modo giusto) è relativamente banale: devi solo dire all'utente cosa stai aspettando che non ci sia, o doesn avere il giusto tipo di valore Puoi renderlo ancora più semplice all'utente se dichiari nel messaggio di errore cose come "le chiavi fanno distinzione tra maiuscole e minuscole" o "le date devono essere immesse in formato dd/mm/yyyy " o qualsiasi altra informazione pertinente.

Il modo in cui tecnicamente implementate dipenderà dalla lingua, ma mantenere un elenco di parametri obbligatori e opzionali (con i loro tipi di valore e valori predefiniti) non è tecnicamente difficile - si potrebbe, in effetti, farlo con un file JSON che sarebbe usato sia come input per il parser sia come fonte per i tuoi documenti.
Costruisci e gestisci questa lista e il gioco è fatto. Avere alcune risorse di testcase e assicurarsi che il parser (e i "costruttori") non riescano a fondo (almeno durante i test automatici) quando manca una proprietà obbligatoria o genera un grosso avvertimento se è presente una proprietà sconosciuta (non in quell'elenco).
Se aggiungete proprietà obbligatorie al vostro codice, ma dimenticate di aggiornare quell'elenco, i vostri testicoli ve lo diranno - sia dal parser che lo rileva, che dai "costruttori" che vi urlano perché mancano dati. Stessa cosa se cambi nomi o tipi di valore.

_{^* Hai formulato la tua domanda in modo tale che tu sembra essere l'utente finale. Ma se il caricamento delle risorse è una caratteristica fondamentale della tua app, tieni presente che ci saranno molte più persone che ci giocheranno.
^** Sostituisci qualsiasi formato qui.}

How would subtle failures (such as a dyslexic spelling of name) be handled?

Test dell'unità. Non so quale lingua stai usando, ma JUnit funziona alla grande in Java e in Scala. Stai scrivendo qualcosa che prende una sorta di input e produce JSON? Inizia facendo un test che alimenta un file di input noto e verifica che l'output sia esattamente quello che desideri. Dopo aver scritto alcuni test, puoi modificare il codice ed eseguire il test per avere la sensazione che la funzionalità di base che esisteva prima funzioni ancora.

Un'altra possibile soluzione è rendere la tua applicazione che legge il JSON veramente bravo a segnalare errori, decidere quando rifiutare l'input e continuare l'elaborazione dopo che si è verificato un errore (errori fatali e non fatali) e correggere piccoli errori comuni .