Errore nella gestione delle best practice per la libreria esterna

Nei vecchi tempi, prima dell'invenzione delle eccezioni, la cosa più dolorosa della codifica era quella di interrompere il tuo programma dal continuare ciecamente dopo aver fallito qualche chiamata API. Dovevi controllare ogni singolo risultato di chiamata di funzione per essere NULL , -1 o qualsiasi cosa il progettista abbia scelto come suo segnale di errore, e quindi per tornare dalla tua funzione al valore di segnalazione di errore. Cose come questa (ad esempio in C):

FILE *fp = fopen(...);
if (fp == NULL) {
    return -1;
}

Una linea di codice produttiva, tre brutti, quelli standard.

Quando si usano le eccezioni, questo è gratuito. Quindi, laddove tecnicamente possibile, utilizzare le eccezioni per segnalare i guasti (ma non tutto è un fallimento, ad esempio quando si cerca una sottostringa in una stringa, non trovandola non si dovrebbe lanciare come è normale). Senza eccezioni, stai forzando i tuoi colleghi in questo brutto stile di codifica.

E inserisci le informazioni sull'errore nell'oggetto eccezione, se non è incluso automaticamente, ad es. il nome del file quando si tenta di aprire un file, quindi il sysadmin che legge il log sa dove cercare il problema.

Quando si utilizzano i servizi REST, consiglierei di includere i codici di errore nelle eccezioni se la libreria REST non lo fa già.

La tua scelta di parole - "DLL" anziché "assembly" - mi dà una pausa.

Generalmente, il modo migliore per gestire gli errori è tramite le eccezioni.

Probabilmente l'unica buona 'eccezione' ;-) a quella regola sarebbe nel caso delle DLL, dove è possibile entrare nei guai generando eccezioni attraverso i confini della DLL.

Tuttavia, uno dei luoghi che funziona meglio è con .net. .Net si presenta come un gruppo di assiemi, quindi lanciare attraverso gli assembly è estremamente comune .

Quindi - in breve - dato che dici che stai usando .net (e questo implica che credo che le tue DLL siano assiemi) - non dovresti avere problemi a lanciare e catturare eccezioni, quindi questa sarebbe la migliore pratica.

In generale, alcuni dei migliori documenti di buone pratiche potrebbero essere utilizzati come base, ad esempio link . Essendo specifiche, le classi di progettazione possono evitare le eccezioni (ovvero non pianificare l'utilizzo della gestione delle eccezioni come parte del flusso normale) poiché influiscono in modo significativo sulle prestazioni (necessità di raccogliere traccia dello stack ecc.), Ma in caso di situazioni eccezionali, un'eccezione dovrebbe essere lanciato invece di restituire booleani, valori predefiniti, ecc. Se si prevede che l'eccezione di lancio faccia parte del flusso normale (un esempio chiaro è quando si analizza una stringa in numero intero ci si aspetta che ci possano essere errori frequenti) è possibile fornire metodi di prova specifici (come TryParseInt) che considerano le prestazioni del sistema .