在我们的应用中,我们使用其他团队开发的组件。问题是如何定义一种比这个
更好的异常处理方式 try
{
someComponent.DoStuff();
}
catch (Exception ex)
{
textLabel= ex.Message;
}
该组件没有自定义异常类型,也许一个很好的方法是定义一个特定于组件的Exception类型并以某种方式包装它? 我知道这个问题非常基本,但我更感兴趣的是,让我们说这样做有多好。如果您调用另一个没有自定义异常类型的组件,您如何以优雅的方式处理任何潜在的异常?
答案 0 :(得分:2)
理想情况下,您可以让组件开发团队为您执行此操作 - 他们还希望客户如何识别和处理其组件中的错误?确定组件可以引发的异常是C#design的基本组成部分。
如果这不是一个选项,那么在组件顶部实现自己的包装器以对其失败案例进行分类,听起来就像是第二好的,并且非常高贵。
答案 1 :(得分:2)
如果第三方库的文档记录很差(它们没有指定每种方法可以抛出的异常),那么可以使用一些工具来反映代码并确定可能引发的异常。这可能会有点令人生畏(对于任何给定的调用,都会抛出令人惊讶的异常数量),但原则上它比捕获常规Exception类型更好。以下是执行此类分析的one commercial product。
答案 2 :(得分:1)
当您发现错误时,您可以重新打包它然后再抛出另一个错误,在最基本的级别上,您可能只是添加更多数据 - 但是,根据您的建议,您还可以替换一般错误一个自定义错误,虽然它不会克服你从组件得到的响应的限制,但会给调用堆栈中的代码提供更适当的响应的机会。
所以就只是以最基本的方式添加信息而言 - 通过在传递原始异常的同时抛出一些额外文本的新异常:
catch (Exception ex)
{
throw new Exception("This is more about where the exception occurred", ex);
}
现在,如果您要定义自己的自定义组件例外,请将new Exception
更改为新ComponentSpecificException
,根据需要将数据添加到构造函数中,但从不忘记设置内在的例外。异常还包含键值对的数据集合,您可以在其中插入更多信息(通过创建异常,添加数据然后执行抛出)。
这一切都相当通用 - 从那里向前工作,在那里你不一定能预见到你必须处理的所有异常都不要尝试 - 你设置了日志记录,以便你知道何时你有一个通用的例外,即击中最终捕获的一个 - 然后随着时间的推移在通用之上添加异常特定的捕获以提供更合适的响应,或者至少将错误打包到不太常见的自定义异常中。
我不确定我是否已经解释得非常好 - 但是这个概念是因为很难预测每一个可能的错误,所以当你发现新的异常时,你想要有一个策略来系统地开发你的应用程序。
答案 3 :(得分:0)
假设你想要捕获每种类型的异常,这个解决方案对我来说很好。
答案 4 :(得分:0)
无论是从使用组件的知识,还是通过使用Reflector之类的东西来分析编译组件,这个组件可能会抛出哪些异常?为这些提供异常处理程序是否可以让您为用户提供更好的反馈?
答案 5 :(得分:0)
处理异常的唯一合理(更少“优雅”)方法是在无法从中恢复时记录它们。
然后通知用户存在问题并为他们提供再次尝试的机会(如果是交互式程序)。
如果您的应用程序专门针对.NET开发人员,请继续向他们展示异常消息(尽管Exception.ToString
更好,因为它包含堆栈跟踪)。否则,不要在用户界面中显示异常消息 - 这是一个安全漏洞,只会让用户感到困惑。