OOP e API: dove archiviare i miei errori, avvisi, notifiche?

Il ritorno di un "enorme array" suona come un incubo per i tuoi utenti. Stai creando un'API. Perché ti stai riprendendo dagli errori piuttosto che riportarli chiaramente? Come potresti sapere quali errori dovrebbero essere recuperati da quando sei solo un'API? Consenti all'utente API di decidere se è necessario recuperare un errore.

Se ciò non semplifica le cose a semplici eccezioni one-shot fail-early, allora accetta un log che puoi usare per registrare gli errori.

Può anche aiutare a creare classi di eccezioni uniche che non aggiungono altro che nomi univoci. Una delle poche cose per le quali utilizzo ancora l'ereditarietà.

Prima di poter pianificare come tenere traccia dei problemi devi pensare ai requisiti reali. Permettetemi di condividere come abbiamo gestito questo (linguaggio diverso, ma lo stesso concetto) in uno strumento di elaborazione file batch:

• L'utente doveva conoscere il successo, l'avviso o l'errore per ogni file
• L'utente ha bisogno della possibilità di correggere i problemi e tentare di reimportare (cioè modificare la mappatura dei campi ecc.)
• L'elaborazione doveva continuare anche se si verificava un problema su una riga o un file

Avevamo una tabella in memoria per monitorare l'elaborazione a livello di file. C'era una colonna per il file, stato (in attesa, elaborazione, successo, errore, avviso) e messaggi. I messaggi erano solo un file CSV con una riga per avviso o errore.

L'elaborazione è stata piuttosto semplice.

• Compila la tabella in memoria con l'elenco di file da elaborare
• Il controller di elaborazione ha aggiornato lo stato e ha chiamato un parser per il file
• Il parser ha restituito il contenuto CSV per tutti gli errori e gli avvisi
• Il controller di elaborazione ha aggiornato di nuovo lo stato e assegnato il CSV alla colonna dei messaggi

L'interfaccia utente è stata in grado di presentare lo stato e consentire all'utente di visualizzare il contenuto dell'elenco degli errori. Era un'app desktop, quindi alcuni di questi aggiornamenti di stato erano facili da fare.

La linea di fondo è che probabilmente dovrai tenere traccia degli errori a più di un livello. La complessità deve corrispondere alle tue reali esigenze.

È possibile passare l'oggetto a cui si sta tracciando il processo a ciascun metodo / componente che deve farvi riferimento oppure è possibile fare in modo che lo stesso codice restituisca la raccolta di stato al chiamante. Rendi chiaro a cosa appartiene il messaggio fornendo qualsiasi identificatore possibile (come nome del file, numero di linea ecc.). Potresti avere errori ripetuti, ma è per record diversi.