我正在寻找一种“优雅”的方法来在调用方法时抑制异常。
我认为以下代码过于冗长:
try
{ CallToMethodThatMayFail(3); }
catch {}
是否有一些语法糖可以用来说“我真的不在乎这种方法是否失败”?我想调用该方法并继续执行,无论该方法发生什么。
答案 0 :(得分:10)
忽略/吞下错误几乎不是一个好主意......
要允许重复使用,您唯一的选择就是采用Action
的方法:
static void IgnoreErrors(Action action) {try {action();} catch {}}
但是当你完成时,你并没有完全节省下来:
SomeHelper.IgnoreErrors(() => CallToMethodThatMayFail(3));
我要离开try
/ catch
......
回答评论中的问题:
static void IgnoreErrors<T>(Action action) where T : Exception
{
try { action(); } catch (T) {}
}
SomeHelper.IgnoreErrors<ParseException>(() => CallToMethodThatMayFail(3));
但我仍然觉得在本地try
/ catch
更清楚......
答案 1 :(得分:5)
不是这样的。
这是一件好事,它很冗长。如果你压制可能的异常,你最好有充分的理由。详细程度将帮助您或下一个在几个月内查看代码的人。
答案 2 :(得分:4)
使用Castle,您可以执行以下操作:
public class ExceptionSuppressionInterceptor : Castle.Core.Interceptor.IInterceptor
{
public void Intercept(IInvocation invocation)
{
try {
invocation.Proceed();
}
catch (Exception ex) {
// Suppressed!
}
}
}
装饰要抑制异常的类,如下所示:
[Interceptor(typeof(ExceptionSuppressionInterceptor))]
public class GoodPracticeBreaker {
}
但你真的可能不应该。
答案 3 :(得分:1)
我不知道更简洁。我想你可以做一些AOP或类似的东西更加花哨。
答案 4 :(得分:1)
答案 5 :(得分:0)
不,没有更好的方法可以做到这一点,并且有充分的理由。您看到的例外可能意味着“方法失败”。这可能意味着“系统失败”。
你可能至少应该记录失败的事实,以防它最终变得重要。
答案 6 :(得分:0)
为什么你说这太冗长了?如果您尝试保存击键,则可以使用代码段。如果你担心可读性,那么我认为AOP方法对于另一个维护者来说不太清楚(至少在最初阶段),对我来说,这超过了冗长。