Costrutti di gestione delle eccezioni F #

Question

Perché F # non supporta in modo naturale un blocco try/with/finally?

Essa non ha senso per provare qualcosa, affare con qualunque eccezione getta, almeno per registrare l'eccezione, e quindi essere sicuri che qualche codice viene eseguito dopo tutto quello che?

Certo, possiamo fare

try 
    try 
     ... 
    with ex -> ... 
finally 
    ... 

ma che sembra troppo artificiale, dimostra chiaramente che "F # è contro try/con/fine". Perché?

Answer 1

Come qualcuno ha già detto, di solito si utilizza try-with-finally per assicurarsi di rilasciare correttamente tutte le risorse in caso di eccezione. Credo che nella maggior parte dei casi si può fare questo più facilmente utilizzando la parola chiave use:

let input = 
    try 
    use stream = new FileStream("C:\temp\test.txt"); 
    use rdr = new StreamReader(stream); 
    Some(rdr.ReadToEnd()) 
    with :? IOException as e -> 
    logError(e) 
    None 

Penso che questo è in gran parte il motivo per cui non è necessario try-with-finally come spesso come si farebbe in altre lingue. Ma ovviamente ci sono alcune situazioni in cui potresti averne bisogno (ma potresti ovviamente evitarlo creando istanza di espressioni di oggetti (che è sintatticamente molto semplice), ma penso che sia così raro che il team di F # in realtà non è necessario preoccuparsi di questo

Answer 2

Ma ciò sembra troppo artificiale, dimostra chiaramente che "F # è contro try/with/finally". Perché?

Immagino che F # potrebbe essere "contro" l'eccezione di gestione a tutti. Per motivi di interoperabilità .NET, deve supportarli, ma in pratica, non esiste alcuna gestione delle eccezioni * nella programmazione funzionale.

Eccezioni di lancio/cattura significa eseguire "salti verso il nulla" che non sono nemmeno notati dal sistema di tipi che è fondamentalmente contrario alla filosofia funzionale.

È possibile utilizzare il codice puramente funzionale (monadico) per avvolgere le eccezioni. Tutti gli errori sono gestiti attraverso i valori, in termini del sistema di tipi sottostante e senza salti/effetti collaterali.

Invece di scrivere una funzione

let readNumber() : int = ... 

che possono generare eccezioni arbitrari, sarà sufficiente dichiarate

let readNumber() : int option = ... 

che rende questo punto automaticamente chiaro la sua firma tipo.

* Ciò non significa che non gestiamo situazioni eccezionali, si tratta solo del tipo di gestione delle eccezioni in .NET/C++.

Answer 3

chiarirò il mio commento in questa risposta.

1. io sostengo non c'è alcun motivo di ritenere che si desidera catturare eccezioni e finalizzare alcune risorse allo stesso livello. Forse ti sei abituato a farlo in quel modo in un linguaggio in cui era conveniente gestirli entrambi allo stesso tempo, ma è una coincidenza quando succede. La finalizzazione è utile quando non si rilevano tutte le eccezioni dal blocco interno. try...with è per la cattura delle eccezioni in modo che il calcolo possa continuare normalmente. Non c'è semplicemente alcuna relazione tra i due (semmai, vanno in direzioni opposte: stai colto l'eccezione, o lascialo passare?).

2. Perché devi finalizzare qualcosa? Il GC non dovrebbe gestire risorse senza riferimento per te? Ah ... ma il linguaggio sta cercando di darti accesso ai primitivi di sistema che funzionano con effetti collaterali, con allocazioni e disallocazione esplicite. Devi de-allocare ciò che hai assegnato (in tutti i casi) ...Non dovresti incolpare l'interfaccia marcia che il sistema sta fornendo invece di F #, che in questo caso è solo il messenger?

Answer 4

Ortogonalità? Puoi semplicemente annidare un try-con all'interno di un try-finally, come mostri. (Questo è ciò che accade a livello di IL comunque, credo.)

Detto questo, provare-con-finalmente è qualcosa che possiamo considerare in una versione futura del linguaggio.

Personalmente ho solo provato a volerlo un paio di volte, ma quando ne hai bisogno, è un po 'fastidioso dover fare il nesting/rientro extra. In generale, trovo che raramente scrivo codice di gestione delle eccezioni, e di solito è solo uno o l'altro (ad esempio, per ripristinare una semantica invariabile o altra transazione, o un 'catch' nella parte superiore di un'app per registrare un'eccezione o uno spettacolo la diagnostica dell'utente).

Ma non penso ci sia molto da "leggere dentro" riguardo al design del linguaggio qui.

Answer 5

senza entrare nei dettagli, perché i grandi dettagli sono in

Expert .NET 2.0 IL Assembler di Serge Lidin

See:. Ch. 14, Exception Handling Managed

"Il finalmente e colpa gestori non possono coesistere pacificamente con altri gestori, quindi se un blocco sorvegliato ha un finalmente o colpa gestore, non può avere altro. Per combinare un gestore finalmente o colpa con altri gestori, è necessario nido custodito e gestore bocks all'interno di altri blocchi custoditi, ..., in modo che ogni finalmente o colpa gestore ha un proprio blocco custodito personali ."

pag. 300

a try/catch utilizza un guasto conduttore e un try/finally utilizza un gestore finalmente.

Vedi: ILGenerator.BeginFaultBlock Method

Se si emettono un guasto gestore in un blocco di eccezione che contiene anche un gestore cattura o un infine gestore, il codice risultante è inverificabile.

Quindi, tutti i linguaggi .net potrebbero essere considerati come l'uso di sintattica surgar e poiché F # è così nuovo, non l'hanno ancora implementato. Nessun danno nessun fould.