Rappresentazione di diversi risultati del metodo tramite il tipo restituito in C #

Direi che questo è letteralmente il classico caso d'uso per le eccezioni. Le eccezioni sono già dotate di un meccanismo di corrispondenza del modello perfettamente valido. Per dirla in parole povere, non c'è alcun vantaggio oltre il fatto che l'eccezione si propaghi verso l'alto e la prenda nel Main (). Ecco come sarà la tua implementazione di ReadFileResult:

public static ReadFileResult ReadFile(string filename)
{
  try {
     return new BytesFileResult(File.ReadAllBytes(filename));
  }
  catch (FileNotFoundException) {
     return new FileNotFoundResult();
  }
}

Potresti farlo per lo stesso effetto, il che ti farebbe risparmiare un sacco di inutili complessità:

class Program
{
    static void Main(string[] args)
    {
        try {
            byte[] readFileResult = ReadFile("test.txt");
            Console.WriteLine(bytesFileResult.Length); 
        }
        catch (FileNotFoundException) {
            Console.WriteLine("File not found");
        }
    }

    public static ReadFileResult ReadFile(string filename)
    {
        File.ReadAllBytes(filename); //some logic here
    }
}

Non dimenticare che ci sono altre IOException che possono accadere quando leggi un file. Vuoi creare ReadFileResults anche per quelli? Questo è solo aggiungere un ulteriore livello di riferimento indiretto senza alcun beneficio evidente.

ASP.NET utilizza il modello a più risultati in quanto è possibile restituire diversi tipi di risultati, non solo contenuti o errori. È possibile restituire una vista, JSON, un reindirizzamento, contenuto non elaborato, vuoto, così via. Questa non è la tua situazione.

Il pattern "risultato dell'errore" di per sé è utile quando devi serializzare il risultato, per esempio, e passarlo attraverso un livello che non supporta le eccezioni.

Hai scelto una lingua, C #, che utilizza eccezioni ovunque, e il tuo caso d'uso sembra essere esattamente ciò che le eccezioni dovrebbero essere utilizzate.

Potresti percepire qualche altro meccanismo per la gestione degli errori (ad esempio la corrispondenza dei modelli sui tipi di risultato come ad esempio in Rust o Haskell) presenta alcuni vantaggi, ma questa è davvero una scelta fatta a livello di lingua. Anche se decidi di utilizzare un meccanismo diverso, il BCL e tutte le librerie di terze parti continueranno a utilizzare le eccezioni, il che significa che dovrai supportare entrambi tipi di gestione degli errori nella tua applicazione allora, e stai andando confondere altri sviluppatori per l'avvio. Semplicemente non c'è una buona ragione per farlo.

La corrispondenza del modello sui tipi di risultato è un modello utile, ma non dovrebbe essere utilizzata come alternativa alle eccezioni.

Le eccezioni dovrebbero essere utilizzate solo quando la funzione ha come risultato un errore. E, se una funzione fallisce, dovrebbe restituire un'eccezione. I codici di ritorno degli errori sono accettabili solo quando le prestazioni sono di importanza assoluta o i validatori di input come Int32.TryParse.

Se una funzione ha bisogno di restituire diversi tipi di risultati "positivi", allora il pattern-matching è in realtà un buon approccio.

Stai chiedendo se il tipo di reso è un buon modo per gestire i risultati multipli.

Di solito ti piacerebbe che un metodo restituisse solo una cosa, perché quella è la cosa più facile da implementare, capire e mantenere.

Questo ci lascia con entrambe le eccezioni per gestire gli errori o suddividere la chiamata di servizio in più chiamate di servizio.

Sono propenso a che Eccezioni sarebbe il modo "corretto" per il tuo scenario, a meno che tu ora i chiamanti chiamino frequentemente il servizio con parametri sbagliati e che danneggino così tanto le prestazioni, quindi sarebbe un problema. (la mia macchina può facilmente elaborare 10000 eccezioni al secondo).

In questo caso, suddividere la chiamata di servizio in più chiamate può essere una buona soluzione, pseudo-codice:

public ActionResult Resize(string path, int width, int height)
{
    if (resizeService.IsValidSize(width, height) == false)
    {
        return new HttpStatusCodeResult(403, "Invalid parameters.");
    }

    if (resizeService.IsValidPath(path) == false)
    {
        return new HttpStatusCodeResult(404, "File not found.");
    }

    var resizeResult = resizeService.Resize(path, width, height);
    return Content(resizeResult);
}

L'unico lato negativo nella mia mente è che se il file viene cancellato / spostato / bloccato, il file potrebbe trovarsi lì quando si chiama resizeService.IsValidPath, ma inaccessibile quando si verifica la chiamata di ridimensionamento effettiva che quindi genera un eccezione.

Vorrei approssimare la probabilità di tale errore e se è improbabile, preferirei mantenere il codice pulito senza aggiungere ulteriore gestione delle eccezioni.

Alcune brave persone qui hanno praticamente sottolineato che le eccezioni qui sarebbero un buon modo per andare e, personalmente, sono d'accordo con loro. Nondimeno, per l'argomento, farò finta di non essere completamente d'accordo con loro e suggerirò un approccio alternativo: usare il polimorfismo.

Invece di avere una clausola switch enorme che dovresti espandere ogni volta che aggiungi un nuovo tipo di errore, puoi semplicemente definire un'azione predefinita da eseguire quando viene creato il risultato. Qualcosa del genere:

public class ReadFileResult
{
    public virtual void Action()
    {
        throw new Exception("Unexpected file result");
    }
}

public class FileNotFoundResult : ReadFileResult
{
    public override void Action()
    {
        Console.WriteLine("File not found");
    }
}

public class BytesFileResult : ReadFileResult
{
    public BytesFileResult(byte[] fileData)
    {
        FileData = fileData;
    }

    public byte[] FileData { get; }

    public override void Action()
    {
        Console.WriteLine(bytesFileResult.FileData.Length); //do something with the data
    }
}

class Program
{
    static void Main(string[] args)
    {
        ReadFileResult readFileResult = ReadFile("test.txt");
        readFileResult.Action();           
    }

    public static ReadFileResult ReadFile(string filename)
    {
        throw new NotImplementedException(); //some logic here
    }
}

Ovviamente, alcune varianti possono essere fatte qui. ReadFileResult può essere una classe astratta o un'interfaccia, costringendo quindi un utente a implementare il tipo che deve essere restituito. Ho scelto qui l'implementazione predefinita che corrisponde al blocco predefinito nell'istruzione switch.

Inoltre, si noterà che Action() è un metodo senza parametri che non ha alcun tipo di ritorno e alcune azioni potrebbero garantire un tipo di ritorno o alcuni parametri. Questo può essere facilmente ottenuto utilizzando l'iniezione di dipendenza. Un buon esempio di questo è mostrato in BytesFileResult class. In alternativa, puoi fornire una raccolta di oggetti che puoi utilizzare come contenitore di qualunque cosa tu abbia bisogno di entrare o uscire dal metodo (non un fan di questa soluzione, ma può essere fatto).