Un'API della libreria di lettori di file dovrebbe generare eccezioni?

Esistono eccezioni per un motivo. Il motivo è essere in grado di segnalare che un metodo non può soddisfare il suo scopo documentato . Se i tuoi dati di input non sono conformi allo standard pubblicato dal metodo, questo è assolutamente un motivo per sollevare un'eccezione.

L'alternativa (restituire un tipo conforme, ma un valore speciale che il chiamante deve ricordare di verificare) è inferiore sotto ogni aspetto. È più facile abusare (basta dimenticare il controllo degli errori). È più difficile da leggere: il codice di controllo degli errori confonde la semantica della chiamata ogni al metodo, mentre un catch FormatException è piuttosto esplicito su ciò che fa. È più semplice delegare la gestione degli errori in un posto più adatto (basta far apparire l'eccezione).

In breve, questo è un caso da manuale per il tipo di evento imprevisto e non risolvibile per cui sono state inventate le eccezioni. Usali; non accettare alcun sostituto.

1. Chiedi:

   Or should I return some sort of result object wrapping, e.g., the data object when it is valid and has been successfully read, or a list of error messages collected during the read when something went wrong? (Should the respective other fields then be null or contain an empty value?)

   Questo dipende molto dal tuo caso d'uso. Se puoi fare qualcosa di utile con i dati analizzati prima che si verifichi un errore o se sono inutili perché non è possibile analizzare l'intero file.

2. eccezioni di runtime rispetto alle eccezioni controllate:

   Questa è una fonte di discussioni altamente emotive. Troverete numerosi argomenti sia per www.

La mia opinione su questo caso è:

• Indipendentemente da ciò che tu / o altri pensano, prova a fare in modo che l'intera libreria si comporti in modo simile.
• Se sei libero nella tua decisione, organizza una riunione con l'intero team di sviluppatori per giungere a una decisione di progettazione che verrà poi utilizzata come standard da tutto il team
• Preferisco utilizzare RuntimeExceptions, ma se non gestisci l'errore non ha senso, puoi considerare un'eccezione controllata.

Sono assolutamente d'accordo con la risposta di Kilian: se il tuo lettore non riesce a completare completamente il suo compito, lancia un'eccezione.

Poi c'è la domanda su quale classe di eccezioni usare. Risposta breve: la classe di eccezione non ha importanza.

Che cosa ti aspetti che gli utenti della tua biblioteca facciano con la notifica di errore (= eccezione)? In genere, vogliono

• registra l'eccezione
• informa l'utente
• prova qualche alternativa (inclusi i tentativi)

La registrazione non interessa la classe di eccezioni, basta fornire un messaggio decente e la registrazione andrà bene.

Informare l'utente in modo intuitivo mentre si forniscono informazioni specifiche sull'eccezione è quasi impossibile, poiché richiede una mappatura completa di tutti i tipi di eccezione ai messaggi amichevoli. Quindi scommetto che la maggior parte delle applicazioni avvolgono la classe e il messaggio di eccezione in un testo del template, o semplicemente danno un messaggio come "Errore durante l'esecuzione di xy". Quindi, ciò che è importante qui è di nuovo il messaggio.

Provare qualche alternativa è qualcosa che difficilmente posso immaginare con una libreria di file reader. In teoria, un'applicazione potrebbe avere un secondo file di fallback che potrebbe leggere nel caso in cui il primo tentativo fallisca, ma non me lo aspetterei. E se il primo tentativo fallisce, l'applicazione proverà comunque il secondo, indipendentemente dal motivo dell'insuccesso. Ancora una volta, il tipo di eccezione non ha importanza.

Ritentare la chiamata fallita può avere senso se l'eccezione implica qualche problema temporaneo. Quindi, qui il codice dell'applicazione è interessato a saperlo, magari introducendo una classe di eccezioni di base come RetryableException . Se vedi una situazione in cui un tentativo ha buone possibilità di successo, fallo in questo modo (ma non lo vedo con un lettore di file).