Nunca he estado del todo contento con la forma en que funciona el manejo de excepciones, hay muchas excepciones y trucos de prueba / captura a la mesa (desenrollado de pila, etc.), pero parece romper mucho el modelo OO en el proceso.

De todos modos, aquí está el problema:

Supongamos que tiene alguna clase que envuelve o incluye operaciones de E / S de archivos en red (por ejemplo, leer y escribir en algún archivo en alguna ruta UNC particular en algún lugar). Por diversas razones, no desea que esas operaciones de E / S falle, por lo que si detecta que fallan, las reintenta y las sigue reintentando hasta que tengan éxito o llegue a un tiempo de espera. Ya tengo una clase RetryTimer conveniente que puedo instanciar y usar para suspender el hilo actual entre los reintentos y determinar cuándo ha transcurrido el período de tiempo de espera, etc.

El problema es que tiene un montón de operaciones de E / S en varios métodos de esta clase, y necesita envolver cada una de ellas en la lógica de prueba-captura / reintento.

Aquí hay un fragmento de código de ejemplo:

RetryTimer fileIORetryTimer = new RetryTimer(TimeSpan.FromHours(10));
bool success = false;
while (!success)
{
    try
    {
        // do some file IO which may succeed or fail
        success = true;
    }
    catch (IOException e)
    {
        if (fileIORetryTimer.HasExceededRetryTimeout)
        {
            throw e;
        }
        fileIORetryTimer.SleepUntilNextRetry();
    }
}

Entonces, ¿cómo evita duplicar la mayor parte de este código para cada operación de E / S de archivos en toda la clase? Mi solución fue usar bloques de delegados anónimos y un solo método en la clase que ejecutó el bloque de delegados que se le pasó. Esto me permitió hacer cosas como esta en otros métodos:

this.RetryFileIO( delegate()
    {
        // some code block
    } );

Me gusta esto un poco, pero deja mucho que desear. Me gustaría saber cómo otras personas resolverían este tipo de problema.