Estoy buscando una manera "elegante" de suprimir excepciones al llamar a un método.¿Cómo se suprimen los errores de una llamada a un método en C#?
Creo que el siguiente código es demasiado detallado:
try
{ CallToMethodThatMayFail(3); }
catch {}
¿Hay algo de azúcar sintáctica que puedo utilizar para decir: "No me importa si este método falla"? Quiero llamar al método y continuar la ejecución independientemente de lo que suceda con el método.
rara vez es una buena idea ignorar/tragar errores ...
Para permitir la reutilización, la única opción que tienes es algo así como un método que toma un Action:
static void IgnoreErrors(Action action) {try {action();} catch {}}
pero no ha guardado mucho exactamente en el momento en que has hecho:
SomeHelper.IgnoreErrors(() => CallToMethodThatMayFail(3));
que acababa de salir de la try/catch en su lugar ...
Re la cuestión en el comentario:
static void IgnoreErrors<T>(Action action) where T : Exception
{
try { action(); } catch (T) {}
}
SomeHelper.IgnoreErrors<ParseException>(() => CallToMethodThatMayFail(3));
pero me sigue pareciendo más clara para que el try/catch localmente ...
¿Hay alguna manera de que pueda tener una función "IgnoreError" que toma AMBAS la función para llamar y el tipo de error para ignorar? De esta forma no ignoraría los errores del sistema, pero podría ignorar los "errores de análisis" si está recorriendo miles de datos ingresados por el usuario. – DevinB
sí ... actualizaré –
@Marc: tienes razón; rara vez es una buena idea hacer esto. Sin embargo, en caso de que quiera hacerlo, ¿cuál es la mejor manera de hacerlo? Aprecio el hecho de que en realidad respondiste las preguntas. No estoy tan agradecido por la falta de respuestas para obtener votos ascendentes. –
No sé nada más escueto. Supongo que podrías hacer algo de AOP o similar por algo más elegante.
Sí, algo AOPish es lo que estaba pensando también. Simplemente no sé cómo hacerlo realmente. –
Algo AOPish ... http://www.postsharp.org/ –
(-1) "No sé" realmente no ayuda. "Supongamos que puedes hacer" no es realmente una respuesta. – DevinB
Nop eso es todo.
Y es bueno que sea detallado. Si suprime una posible excepción, es mejor que tenga una muy buena razón. La verbosidad lo ayudará a usted o a la próxima persona que vea el código en unos pocos meses.
Con todo el debido respeto: puedo tomar una decisión sobre si tengo una buena razón para suprimir la excepción. También está asumiendo que este es un código que otra persona realmente verá. –
No, no hay mejor manera de hacerlo, y hay una buena razón para ello. La excepción que ve puede significar más que "el método falló". Puede significar que "el sistema está fallando".
Probablemente debería al menos registrar el hecho de la falla, en caso de que resulte ser importante después de todo.
Usando Castillo, se podría hacer algo como esto:
public class ExceptionSuppressionInterceptor : Castle.Core.Interceptor.IInterceptor
{
public void Intercept(IInvocation invocation)
{
try {
invocation.Proceed();
}
catch (Exception ex) {
// Suppressed!
}
}
}
y decorar la clase que desea suprimir las excepciones de la siguiente manera:
[Interceptor(typeof(ExceptionSuppressionInterceptor))]
public class GoodPracticeBreaker {
}
Pero en realidad, probablemente no debería.
¡Rompedor de buenas prácticas! :) – Groo
¿Por qué dices que esto es demasiado detallado? Si está intentando guardar las pulsaciones de teclas, puede usar un fragmento de código. Si le preocupa la legibilidad, entonces creo que un método de AOP sería menos claro para otro mantenedor (al menos inicialmente) y para mí, esto supera la verbosidad.
La convención de .Net es que las clases implementan un método TryCallMayFail() y un método CallMayFail() y el llamador elige cuál usar pero el método TryCallMayFail() incluiría exactamente lo que tiene allí.
Todas las clases? Todos los metodos –
No todos pero algunos de ellos y es un estilo al que me he acostumbrado – SpaceghostAli
Parece que quieres VB desagradable, como On Error Resume Next function in C#! – RichardOD
Creo que probablemente sea tan elegante como puedas conseguir. Pasar a una función para manejar el error probablemente sea más confuso. No confiaría en el manejo de errores para ignorar los errores. Recomendaría probar los casos de error esperados que desea ignorar y simplemente manejarlos en su código. Plantear una excepción es más costoso en términos de rendimiento que un enunciado condicional. –
Me gustaría señalar a todos que hay situaciones de nicho cuando esta es una buena idea. Al igual que hoy, tuve que modificar algunos códigos que leen una cuadrícula de datos creada dinámicamente que simplemente crea columnas basadas en nombres de filas desde una VISTA SQL. Ocasionalmente, la vista cambia y esto funciona bien en el código, esta vista también puede usarse en otros lugares. Para esta página web, necesitaba las columnas nombradas de cierta manera, pero no quiero que se rompa el código si alguien cambia la VISTA en el futuro. – TravisO