【发布时间】:2010-01-28 16:22:33
【问题描述】:
是否有任何关于在方法签名中返回布尔值以指示成功操作而不是声明无效的硬性规则?我发现对于我的调用方法中更关键的操作,我想知道一个操作是否完成,以便我可以记录任何问题。这是对布尔值的“不当”使用吗?
【问题讨论】:
是否有任何关于在方法签名中返回布尔值以指示成功操作而不是声明无效的硬性规则?我发现对于我的调用方法中更关键的操作,我想知道一个操作是否完成,以便我可以记录任何问题。这是对布尔值的“不当”使用吗?
【问题讨论】:
通常我使用Exceptions 来表示出现问题。
您可以通过throw 和Exception 提供有关问题所在的详细消息,而不是返回false。
返回false 不会为您提供有关问题的太多信息。
然后,不要检查false 返回值,如果您认为该方法很容易失败,只需将方法调用放入try/catch。
很多人会抱怨这种方法比较慢。但是,您获得的好处大大超过了减速。此外,如果您使用 Java,速度不应该是您的第一大问题。
【讨论】:
我通常发现在失败的情况下抛出异常是比返回布尔值更好的解决方案,因为通常不关心进程是否成功 - 我只关心它是否失败。通过使用异常,我可以提供有关进程实际失败原因的任何信息。
如果异常看起来令人反感,您可以返回包含布尔值和状态消息的自定义状态对象(类似于“添加了 6 个新的 Foobars!”或“无法添加 Foobars,因为 Foobin 已满!”),尽管那当然更复杂。
【讨论】:
仅在很明显某事物具有布尔结果的情况下才这样做。比如IsValidCustomer() 之类的。
对于您认为可以介绍它的所有其他事情,这可能意味着您正在处理某种Exception,并且您真的不想用简单的方法来包装它boolean true/false,因为您可以有多种口味(不同的例外)以及出现问题的原因,您想知道这些。
所以要么让异常在堆栈中冒泡,要么捕获它并将其转换为自定义异常或记录它或其他任何方式。
【讨论】:
使用布尔值表示非异常失败结果。一个例子是搜索功能。名义上的失败将是未找到。用异常来传达结果是不方便的。为例外情况保存例外情况; not-found 和 cannot-search 之间的区别。
【讨论】:
这是一个不错的范例,但如果您想强制调用者处理操作未成功完成的情况,您可能希望抛出一个检查异常。
不过,这种模式确实出现在核心 Java 库中。以File.delete() 为例。
【讨论】:
为了返回成功,您通常看到的是:
返回布尔值表示成功不会有任何问题,除非您需要有关异常行为的信息。
【讨论】:
如果出现意外结果,则抛出异常。 如果你只是想让函数告诉你“我做了 X”,那么返回一个布尔值。
【讨论】:
在实践中,当失败意味着我们需要中止进程时,我发现抛出异常是最好的做法。例如,如果您正在尝试处理订单——向客户开具账单、安排运输、支付销售税等——如果找不到订单记录,那么进行所有其他工作可能毫无意义。你只是想离开那里。例外让您轻松做到这一点。只需抓住块的底部,显示或记录错误,然后退出。
另一方面,如果“错误”意味着我的程序采用不同的流程路径,则返回布尔值更有意义。就像,如果我正在寻找一个特定的客户,如果他存在,我会更新他的记录,如果他不存在,我会创建一个新的客户记录,那么返回一个布尔值是很有意义的,并在调用者中测试它真时走一条路,假时走另一条路。
真的,这是“错误”这个词的两种截然不同的含义,它们需要不同的处理方式。同一个功能很可能两者兼而有之。比如,找到返回 true,未找到返回 false,尝试读取 I/O 错误时抛出异常。
【讨论】:
看起来不错,但魔鬼藏在细节中。 ;-)
抛出异常是主要的选择,有利也有弊。
我认为您可以通过提供精确的编码示例来获得更多洞察力...
【讨论】: