是否有从工具包API抛出异常的最佳实践或行业标准?
面向方法的用户是否应该捕获Exception
并将其包装在某种CustomException
中,这样用户就只需要担心CustomException
会从API中走出来?
或者,惯例就是让这些泡沫浮出水面?
我们关心的是能够记录API方法可能抛出的所有可能的异常。(例如,如果我们的API方法调用抛出4或5个异常的Stream.Write()
,那么除了其他被调用方法可能抛出的其他异常之外,我们还必须记录所有这些异常。)
我们正在考虑做这样的事情:
public void customerFacingApiMethod(){
try {
//api functionality goes here
} catch (Exception e) {
throw new CustomException(e);
}
}
发布于 2009-12-03 21:52:31
在我看来,让API只抛出一种异常类型不是一个好主意。使用不同异常的好处之一是,您可以选择捕获不同类型的异常,并以不同的方式处理它们。将异常包装到单个异常类型中将删除该工具。
在适当的地方使用框架提供的异常类型,并在适当的情况下为特定情况创建您自己的自定义异常类型。最重要的是,确保为每个方法记录它们可能抛出的异常。
发布于 2009-12-03 21:57:34
当抛出异常时,请确保面向用户的异常都与用户在工具包方面实际做错了什么相关。这可能意味着捕获不同的文件系统异常或将其合并为单个异常,但您不应该只捕获异常并抛出新的异常-这实际上并不是告诉工具包用户他们做错了什么。
发布于 2009-12-03 21:57:36
您应该遵循与.NET框架相同的概念。您的用户已经在使用该框架,因此他们知道它是如何工作的,并期望特定的行为。
如果来自客户端的参数无效,
ArgumentException
-derived异常(使用ArgumentNullException
、ArgumentOutOfRangeException
等作为IO错误的IOException
-derived异常。等等。
在您的文档中,清楚地说明公共API的前提条件,并说明当它们失败时将引发的异常(就像MSDN一样)。
https://stackoverflow.com/questions/1843170
复制相似问题