【发布时间】:2021-05-10 09:58:33
【问题描述】:
在阅读了一些关于该主题的内容后,我仍然不确定 何时 提供 TryGet*(someParameter, out someValue) 方法。 我理解当存在可以在失败的情况下抛出异常的方法的变体时它是如何有用的,但是我不能真正形成一个通用规则来帮助我决定何时提供任何一种方法.
对此想到的一些问题:
- 为什么不让非 try 方法不抛出异常?
- 什么时候抛出异常比只返回 null 更好?
- 如果决定使用一种仅返回可空类型(或某些结果类型)的方法,是否应该始终反映在方法名称中,因为它必须以“Try”为前缀?
- 在每种情况下提供这两种方法总是更好吗?
我专门处理一个集合,我有一堆方法,比如:
void GetAt(position)
bool TryGetAt(position, out item)
我不确定这是否需要,但感觉我所做的在某种程度上是错误的。
【问题讨论】:
-
请注意,例如
TryParse方法是专门出于性能原因而添加的——虽然抛出异常相对很快,但如果你有一个紧密的循环试图解析数字而失败,那就很重要了。至于写什么——这取决于调用者希望方法做什么。如果调用者期望方法失败,调用TryXXX方法会更容易。如果调用者希望方法成功,则抛出异常总体上会减少噪音(并让您说出为什么会发生失败)。失败时尽量不要返回null -
null可以是方法的有效返回值。所以在出错的情况下返回null是不好的。 -
您的方法是否应该抛出异常本质上是另一个问题,此处已对其进行了广泛描述:docs.microsoft.com/dotnet/standard/exceptions/…。也看看这个帖子:softwareengineering.stackexchange.com/questions/120355/…
-
很难知道一个方法是否可以返回 null,从而导致错误或代码臃肿的 null 检查。这已经通过可空引用类型得到缓解,但这是一个相当新的范例。 try 模式是明确的,因此被错误使用的风险较小。
标签: c# .net design-patterns