我在MSDN中挖掘并发现这篇文章有一些有趣的建议:没有公共成员可以抛出或不抛出基于某些选项的异常.
例如:
Uri ParseUri(string uriValue, bool throwOnError)
当然,我可以看到,在99%的情况下,这将是可怕的,但它偶尔使用是否合理?
我看到它使用的一种情况是在访问数据库或配置文件中的数据时使用"AllowEmpty"参数.例如:
object LoadConfigSetting(string key, bool allowEmpty);
在这种情况下,替代方法是返回null.但是调用代码会被空引用检查.(并且该方法还将排除实际允许null作为特定可配置值的能力,如果您如此倾向).
你的想法是什么?为什么这会是一个大问题?
我认为投掷/不投掷决定基于布尔值肯定是个坏主意.也就是因为它要求开发人员查看一段代码以获得API的功能知识,以确定布尔的含义.这本身就很糟糕,但当它改变底层错误处理时,它可以使开发人员在阅读代码时很容易出错.
在这种情况下,拥有2个API会更好,更具可读性.
Uri ParseUriOrThrow(string value); bool TryParseUri(string value, out Uri uri);
在这种情况下,它100%清楚这些API的作用.
关于为什么布尔值不好作为参数的文章:http://blogs.msdn.com/jaredpar/archive/2007/01/23/boolean-parameters.aspx