Qual è il modo migliore per restituire il messaggio di errore dalla funzione?

Question

Se faccia un errore di errore logico tale (Expired user, invalid ID), allora qual è il modo migliore per raccontare il metodo principale di questo errore dal seguente:

1- Lanciare eccezioni personalizzate come la seguente:

try 
{ 
//if (ID doesn't match) then 
Throw new CustomException(-1,"ID doesn't match"); 
} 
catch(CustomException ex) 
{ 
throw ex 
} 
catch(Exception ex) 
{ 
throw new CustomException(ex.ErrorCode,ex.message); 
} 

2 - messaggio di errore di ritorno e il codice come:

//if (ID doesn't match) then 
This.ErrorCode= -1; 
This.Message= "ID doesn't match"; 

Answer 1

Il modo migliore è quello di gettare eccezione personalizzata. Ecco perché sono stati introdotti. Se è necessario fornire informazioni specifiche, ad esempio ErrorCode o altro, è possibile estendere facilmente la classe di base Exception per farlo. Le ragioni principali sono:

• È possibile ignorare il codice di errore non valido restituito dal funcion e questo potrebbe portare a una situazione in cui il vostro stato di sistema è corrotto, mentre Exception è qualcosa che non si può ignorare.
• Se la tua funzione fa qualcosa di utile allora dovrebbe restituire alcuni dati che ti interessano e non i codici di errore, questo ti dà una progettazione più solida.

Answer 2

Nella maggior parte dei casi è necessario generare un'eccezione. Se questa è un'eccezione standard o personalizzata dipende dal contesto, ma è irrilevante per il processo.

L'eccezione di lancio forza qualsiasi implementazione a gestire i dati errati di conseguenza. Se si affidano alle implementazioni per verificare i valori delle proprietà per l'elaborazione corretta, prima o poi si incontreranno eccezioni impreviste, più difficili da debugare.

Answer 3

Suppongo che dovresti usare le eccezioni, perché è esatto, per cosa sono fatte. Puoi inserire le stesse informazioni, come nel secondo caso. Ma la differenza tra l'1 ° e il 2 ° è che dai ai tuoi utenti la possibilità di essere informati che qualcosa non va, e che lo DEVE essere lo in qualche modo gestito. Nel secondo caso si dice semplicemente che la funzione ha funzionato, ma qualcosa di sbagliato e l'utente MAGGIO gestisce queste informazioni

Answer 4

Dipende interamente dal flusso di lavoro del progetto. Se si tratta di un errore del timer di esecuzione imprevisto e si inibisce il programma, l'eccezione è una buona scelta ma per semplici controlli di input e output prevedibili è necessario utilizzare gli enumeratori

Answer 5

Se si verifica un errore di errore logico tale (Utente scaduto, ID non valido), allora qual è il modo migliore per raccontare il metodo principale di questo errore

1. Dal momento che si desidera che il metodo padre di conoscere l'errore, cuciture che non si è sicuri che ID è valido e il User non è scaduto prima di chiamare il metodo GetUser. Destra?

2. Se non si è certi che i parametri passati alla funzione siano validi, l'utilizzo delle eccezioni non è giustificato e si dovrebbero restituire invece le informazioni sull'errore.

3. È possibile restituire informazioni di errore in modo più funzionale simile a quello suggerito dai linguaggi Scala, Go e Rust.

creare una classe generica per restituire sia un errore o un valore

public class Either(of ErrorType, ValueType) 
    public readonly Success as boolean 
    public readonly Error as ErrorType 
    public readonly Value as ValueType 

    public sub new(Error as ErrorType) 
     me.Success = False 
     me.Error = Error 
    end sub 

    public sub new(Value as ValueType) 
     me.Success = True 
     me.Value = Value 
    end sub 
end class 

Creare un'enumerazione di errori che la funzione può avere

public enum UserError 
    InvalidUserID 
    UserExpired 
end enum 

creare una funzione che prende un utente ID come argomento e restituisce un errore o un utente

.210

Nel metodo chiamante (genitore) assegno per l'errore e applicare la logica di business

dim UserID = 10 
dim UserResult = GetUser(10) 

if UserResult.Success then 
    rem apply business logic to UserResult.Value 
else 
    rem apply business logic to UserResult.Error 
end if 

Nota: se si riscrive il codice utilizzando eccezioni si ottiene esattamente la stessa quantità di codice.