Se puede construir su propio método de ayuda en el maravilloso para encapsular esta lógica de reintento.
def retry(int times = 5, Closure errorHandler = {e-> log.warn(e.message,e)}
, Closure body) {
int retries = 0
def exceptions = []
while(retries++ < times) {
try {
return body.call()
} catch(e) {
exceptions << e
errorHandler.call(e)
}
}
throw new MultipleFailureException("Failed after $times retries", exceptions)
}
(Asumiendo una definición de MultipleFailureException similar a GPars' AsyncException)
a continuación en el código, se puede utilizar este método de la siguiente manera.
retry {
errorProneOperation()
}
o, con un número diferente de reintentos y el comportamiento de la gestión de errores:
retry(2, {e-> e.printStackTrace()}) {
errorProneOperation()
}
Ahora bien, si el 'IllegalStateException' usaría una de las excepciones (el primero el último disco que decir??) Como su causa sería ** mucho ** más útil, como se podía ver ** por qué ** falló. En producción, no me gustaría imprimir una pila cada vez que fallara un intento. Solo quiero saber si todos los intentos han fallado. –
Gracias Joachim: a sugerencia de usted, agregué la recopilación de excepciones individuales. En cuanto a no querer una acumulación de pila, seguro, está ahí para ilustrar el punto. Como las excepciones ahora se recopilan para informar al final, tal vez el propósito del errorHandler es restablecer los recursos necesarios antes de que 'body.call()' se reintente, en cuyo caso el cierre predeterminado podría ser '{->} ' – winstaan74
Terminé usando algo muy similar. gracias winstaan. –