Come controllo Stream.Null?

Question

Ho un servizio WCF che restituisce un flusso molto simile al seguente:

public Stream StreamFile(string filepath) 
{ 
    try 
    { 
     // Grab the file from wherever it is 
     // Throw an exception if it doesn't exist 
     return fileStream; 
    } 
    catch (Exception ex) 
    { 
     // Log the exception nicely in a place of my user's choosing 
    } 
    return Stream.Null; 
} 

ho usato per tentare di restituire null, ma ho cominciato a correre in questo problema se il file non è stato trovato: WCF - MessageBodyMember - Stream - "Value cannot be null"

Restituendo Stream.Null, mi sono liberato di quell'errore, ma ora ho un altro problema: come fa il mio cliente a sapere se ho inviato di nuovo Stream.Null? Non posso/non devo controllare la lunghezza, perché questi file possono essere abbastanza grandi, ma anche se non lo fossero, mi troverei di fronte a questo problema: Find Length of Stream object in WCF Client?

Ecco il mio (molto semplificato) codice cliente , solo per i posteri, ma il problema per me con il solo download di Stream.Null è che finisco con un file vuoto, e a nessuno piace.

public FileInfo RetrieveFile(string fileToStream, string directory) 
{ 
    Stream reportStream; 
    string filePath = Path.Combine(directory, "file.txt"); 
    using (Stream incomingStream = server.StreamFile(fileToStream)) 
    { 
     if (incomingStream == null) throw new FileExistsException(); // Which totally doesn't work  
     using (FileStream outgoingStream = File.Open(filePath, FileMode.Create, FileAccess.Write)) 
     { 
      incomingStream.CopyTo(outgoingStream); 
     } 
    } 
    return new FileInfo(filePath); 
} 

Sembra che io sto solo la progettazione di questo metodo sbagliato in qualche modo, ma non riesco a pensare ad un modo migliore per farlo che non comporta un'eccezione non rilevata. Eventuali suggerimenti?

Answer 1

Quando accade qualcosa di inaspettato in un servizio WCF (o qualsiasi altro servizio ben progettato), il cliente non può/non deve conoscere i dettagli o la cura. Tutto ciò che serve per sapere che qualcosa è andato storto.

È necessario consentire l'aumento dell'eccezione senza rilevarlo e il client potrebbe sapere che si è verificato un errore e l'operazione non è riuscita, indipendentemente dal fatto che il file fosse mancante, nessun permesso di leggerlo o che il file sia corrotto disco. Nulla di ciò è importante per il cliente, dal momento che non posso fare nulla con le informazioni in ogni caso, tranne che per essere troppo accoppiata al servizio.

In tal caso, ovviamente, il valore restituito è privo di significato e in effetti il ​​proxy si troverebbe (generalmente) in uno stato di errore e non sarebbe più utilizzabile. (Dipende dalla modalità di sessione e dallo stile di vita delle istanze).

Si noti che se si desidera far conoscere al cliente i guasti e reagire, è necessario progettare tali errori come parte del contratto e lanciare un FaultException<> avvolgendo l'eccezione contratta dichiarata esplicitamente nel contratto. Ciò consentirebbe al proxy di continuare a essere utilizzabile. Puoi leggere di più here