c# - ¿Cómo reviso Stream.Null?

wcf

Question

Tengo un servicio WCF que devuelve un flujo muy parecido al siguiente:

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;
}

Intenté devolver nulo, pero comencé a encontrarme con este problema si no se podía encontrar el archivo: WCF - MessageBodyMember - Stream - "El valor no puede ser nulo"

Al devolver Stream.Null, me deshice de ese error, pero ahora tengo otro problema: ¿cómo sabe mi cliente si le devolví Stream.Null? No puedo / no debo verificar la longitud, porque estos archivos pueden ser bastante grandes, pero incluso si no lo fueran, me encontraría con este problema: ¿ Encontrar el objeto Length of Stream en WCF Client?

Este es mi código de cliente (muy simplificado), solo para la posteridad, pero el problema para mí al descargar Stream.Null es que termino con un archivo vacío, y a nadie le gusta eso.

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);
}

Parece que estoy diseñando mal este método de alguna manera, pero no puedo pensar en una mejor manera de hacerlo que no implique lanzar una excepción no detectada. ¿Alguna sugerencia?

Answer 1

Cuando sucede algo inesperado en un servicio de WCF (o cualquier servicio bien diseñado para ese asunto), el cliente no puede / no debe saber los detalles o la atención. Todo lo que necesita saber es que algo salió mal.

Debe permitir que la excepción aumente sin capturarla y el cliente sabrá que se produjo una falla y la operación falló, independientemente del hecho de que el archivo no estaba, no tiene permisos para leerlo o tal vez el archivo está dañado en el disco. Nada de eso le importa al cliente, ya que no puedo hacer nada con la información de todos modos, salvo por estar demasiado vinculado al servicio.

En ese caso, por supuesto, el valor de retorno no tiene sentido y, de hecho, el proxy estaría (generalmente) en estado de error y ya no sería utilizable. (Esto depende de tu modo de sesión y estilo de vida de la instancia).

Tenga en cuenta que si desea informar al cliente acerca de las fallas y reaccionar, debe diseñar esas fallas como parte del contrato y lanzar una FaultException<> la excepción contratada que declaró explícitamente en el contrato. Esto permitiría que el proxy siga siendo utilizable. Puedes leer más aquí