Catturare / lanciare eccezioni rende impuro un metodo altrimenti puro?

I seguenti esempi di codice forniscono un contesto alla mia domanda.

La classe Room viene inizializzata con un delegato. Nella prima implementazione della classe Room, non ci sono guardie contro i delegati che generano eccezioni. Tali eccezioni saliranno alla proprietà North, in cui viene valutato il delegato (nota: il metodo Main () dimostra come viene utilizzata un'istanza Room nel codice client):

public sealed class Room
{
    private readonly Func<Room> north;

    public Room(Func<Room> north)
    {
        this.north = north;
    }

    public Room North
    {
        get
        {
            return this.north();
        }
    }

    public static void Main(string[] args)
    {
        Func<Room> evilDelegate = () => { throw new Exception(); };

        var kitchen = new Room(north: evilDelegate);

        var room = kitchen.North; //<----this will throw

    }
}

Dato che preferirei non riuscire a creare l'oggetto piuttosto che leggere la proprietà North, cambio il costruttore in privato e introduco un metodo factory statico chiamato Create (). Questo metodo rileva l'eccezione generata dal delegato e genera un'eccezione wrapper con un messaggio di eccezione significativo:

public sealed class Room
{
    private readonly Func<Room> north;

    private Room(Func<Room> north)
    {
        this.north = north;
    }

    public Room North
    {
        get
        {
            return this.north();
        }
    }

    public static Room Create(Func<Room> north)
    {
        try
        {
            north?.Invoke();
        }
        catch (Exception e)
        {
            throw new Exception(
              message: "Initialized with an evil delegate!", innerException: e);
        }

        return new Room(north);
    }

    public static void Main(string[] args)
    {
        Func<Room> evilDelegate = () => { throw new Exception(); };

        var kitchen = Room.Create(north: evilDelegate); //<----this will throw

        var room = kitchen.North;
    }
}

Il blocco try-catch rende impuro il metodo Create ()?

Sì. Questa è effettivamente una funzione impura. Crea un effetto collaterale: l'esecuzione del programma continua in un luogo diverso dal luogo in cui si prevede che la funzione ritorni.

Per renderlo una funzione pura, returnun oggetto reale che incapsula il valore atteso dalla funzione e un valore che indica una possibile condizione di errore, come un Maybeoggetto o un oggetto Unità di lavoro.

Bene, sì ... e no.

Una funzione pura deve avere la Trasparenza referenziale , ovvero dovresti essere in grado di sostituire qualsiasi possibile chiamata a una funzione pura con il valore restituito, senza modificare il comportamento del programma. ^{* La} tua funzione è garantita sempre per determinati argomenti, quindi non esiste un valore di ritorno con cui sostituire la chiamata di funzione, quindi ignoriamola . Considera questo codice:

{
    var ignoreThis = func(arg);
}

Se funcè puro, un ottimizzatore potrebbe decidere che func(arg)potrebbe essere sostituito con il suo risultato. Non sa ancora quale sia il risultato, ma può dire che non viene utilizzato, quindi può semplicemente dedurre questa affermazione senza alcun effetto e rimuoverlo.

Ma se func(arg)succede, questa affermazione fa qualcosa - genera un'eccezione! Quindi l'ottimizzatore non può rimuoverlo: importa se la funzione viene chiamata o meno.

Ma...

In pratica, questo conta molto poco. Un'eccezione - almeno in C # - è qualcosa di eccezionale. Non dovresti usarlo come parte del tuo normale flusso di controllo - dovresti provare a prenderlo e se lo fai prendi qualcosa, gestisci l'errore per ripristinare ciò che stavi facendo o in qualche modo ancora realizzarlo. Se il tuo programma non funziona correttamente perché un codice che avrebbe fallito è stato ottimizzato, stai usando le eccezioni sbagliate (a meno che non sia un codice di test e quando costruisci per le eccezioni dei test non dovrebbe essere ottimizzato).

Detto ciò...

Non gettare eccezioni dalle funzioni pure con l'intenzione che vengano catturate - c'è una buona ragione per cui i linguaggi funzionali preferiscono usare le monadi invece delle eccezioni impilabili.

Se C # avesse una Errorclasse come Java (e molte altre lingue), avrei suggerito di lanciare un Errorinvece di un Exception. Indica che l'utente della funzione ha fatto qualcosa di sbagliato (ha superato una funzione che genera) e tali cose sono consentite nelle funzioni pure. Ma C # non ha una Errorclasse e le eccezioni dell'errore di utilizzo sembrano derivare Exception. Il mio suggerimento è di lanciare un ArgumentException, chiarendo che la funzione è stata chiamata con un argomento negativo.

^* _{Computazionalmente parlando. Una funzione di Fibonacci implementata usando l'ingenua ricorsione richiederà molto tempo per grandi numeri e potrebbe esaurire le risorse della macchina, ma queste poiché con un tempo e una memoria illimitati la funzione restituirà sempre lo stesso valore e non avrà effetti collaterali (oltre all'allocazione memoria e alterare quella memoria) - è ancora considerato puro.}

Una considerazione è che il blocco try - catch non è il problema. (Basato sui miei commenti alla domanda sopra).

Il problema principale è che la struttura a North è una chiamata di I / O .

A quel punto nell'esecuzione del codice, il programma deve verificare l'I / O fornito dal codice client. (Non sarebbe rilevante che l'input abbia la forma di un delegato o che l'input sia stato, nominalmente, già passato).

Una volta perso il controllo dell'input, non è possibile assicurarsi che la funzione sia pura. (Soprattutto se la funzione può essere lanciata).

Non sono chiaro il motivo per cui non si desidera controllare la chiamata a Sposta stanza [Controlla]? Secondo il mio commento alla domanda:

Sì. Cosa fai quando esegui il delegato puoi lavorare solo la prima volta o restituire una stanza diversa alla seconda chiamata? Chiamare il delegato può essere considerato / causare un effetto collaterale stesso?

Come ha detto Bart van Ingen Schenau sopra,

La tua funzione Crea non ti protegge dall'ottenere un'eccezione quando ottieni la proprietà. Se il tuo delegato lancia, nella vita reale è molto probabile che venga lanciato solo in determinate condizioni. È probabile che le condizioni per il lancio non siano presenti durante la costruzione, ma sono presenti quando si ottiene la proprietà.

In generale, qualsiasi tipo di caricamento lento difende implicitamente gli errori fino a quel momento.

Suggerirei di utilizzare un metodo Sposta [Controlla] stanza. Ciò consentirebbe di separare gli aspetti I / O impuri in un unico posto.

Simile alla risposta di Robert Harvey :

Per renderlo una funzione pura, restituisci un oggetto reale che incapsula il valore atteso dalla funzione e un valore che indica una possibile condizione di errore, come un oggetto Maybe o un oggetto Unit of Work.

Spetterebbe al writer del codice determinare come gestire la (possibile) eccezione dall'input. Quindi il metodo può restituire un oggetto Room, o un oggetto Null Room, o forse eliminare l'eccezione.

Dipende da questo punto:

• Il dominio Room considera le eccezioni room come Null o Something Peggio.
• Come notificare il codice client chiamando North su una Null / Exception Room. (Cauzione / Variabile di stato / Stato globale / Restituzione di una monade / Qualunque cosa; alcuni sono più puri di altri :)).

Hmm ... Non mi sentivo bene. Penso che quello che stai cercando di fare sia assicurarti che altre persone facciano bene il loro lavoro, senza sapere cosa stanno facendo.

Poiché la funzione viene passata dal consumatore, che potrebbe essere scritta da te o da un'altra persona.

Cosa succede se la funzione pass-in non è valida per essere eseguita al momento della creazione dell'oggetto Room?

Dal codice, non potevo essere sicuro di cosa stesse facendo il Nord.

Supponiamo che, se la funzione è quella di prenotare la stanza, e abbia bisogno del tempo e del periodo di prenotazione, otterresti un'eccezione se non hai le informazioni pronte.

E se fosse una funzione di lunga durata? Non vorrai bloccare il tuo programma durante la creazione di un oggetto Room, cosa succede se devi creare un oggetto 1000 Room?

Se tu fossi la persona che scriverà al consumatore che consuma questa classe, ti assicureresti che la funzione passata sia scritta correttamente, vero?

Se c'è un'altra persona che scrive al consumatore, potrebbe non conoscere la condizione "speciale" di creare un oggetto Room, che potrebbe causare esecuzione e si griderebbero la testa cercando di scoprire perché.

Un'altra cosa è che non è sempre una buona cosa lanciare una nuova eccezione. Il motivo è che non conterrà le informazioni dell'eccezione originale. Sai di avere un errore (un mesaage amichevole per un'eccezione generica), ma non sapresti quale sia l'errore (riferimento null, indice fuori limite, dividere per zero ecc.). Questa informazione è molto importante quando dobbiamo investigare.

Dovresti gestire l'eccezione solo quando sai cosa e come gestirla.

Penso che il tuo codice originale sia abbastanza buono, l'unica cosa è che potresti voler gestire l'eccezione su "Main" (o qualsiasi livello che sappia gestirlo).

Non sarò d'accordo con le altre risposte e dirò di no . Le eccezioni non fanno impurire una funzione altrimenti pura.

Qualsiasi uso di eccezioni potrebbe essere riscritto per utilizzare controlli espliciti per risultati di errore. Le eccezioni potrebbero essere considerate zucchero sintattico. Lo zucchero sintattico conveniente non impura il puro codice.