何时何地应使用void（而不是例如bool / int）

我偶尔会碰到一些方法，开发人员选择返回一些对函数不重要的东西。我的意思是，当看代码时，它显然void和一样好，并且经过一会儿思考，我问“为什么？” 这听起来很熟悉吗？

有时我会同意，通常最好返回一个诸如boolor的值int，而不是仅仅做一个void。从总体上看，我不确定优缺点。

根据情况，返回int可以使调用方知道受该方法影响的行或对象的数量（例如，将5条记录保存到MSSQL）。如果“ InsertSomething”之类的方法返回布尔值，那么我可以将设计为true成功的方法返回，否则返回false。呼叫者可以选择对该信息采取行动或不采取行动。

另一方面，

• 会导致方法调用的目的不明确吗？错误的编码经常迫使我仔细检查方法的内容。如果返回某些内容，它将告诉您该方法的类型必须对返回的结果进行某些处理。
• 另一个问题是，如果您不知道方法的实现，那么开发人员决定返回什么功能并不关键的东西？您当然可以发表评论。
• 当处理可以在方法的右括号中结束时，必须处理返回值。
• 引擎盖下会发生什么？调用的方法是否false由于抛出错误而得到？还是由于评估结果而返回false？

您对此有何经验？您将如何处理？

在布尔值返回值指示方法成功或失败的情况下，我更喜欢Try在.NET方法中使用的-prefix范式。

例如，void InsertRow()如果已经存在具有相同键的行，则方法可能引发异常。问题是，假设调用者在调用InsertRow之前确保其行是唯一的，是否合理？如果答案是否定的，那么我还将提供一个bool TryInsertRow()如果行已存在则返回false的值。在其他情况下，例如数据库连接错误，假设保持数据库连接是调用者的责任，TryInsertRow仍可能引发异常。

恕我直言，返回“状态代码”源于历史，当时在中高级语言（例如C＃）中，异常变得司空见惯。如今，如果某些意外错误阻止您的方法成功，则最好引发异常。这样可以确保不会引起错误，并且调用者可以适当地处理它。因此，在这些情况下，方法最好不返回任何值（即void），而不是布尔状态标志或整数状态码。（当然，应该记录该方法可能引发什么异常以及何时抛出该异常。）

另一方面，如果严格意义上讲它是一个函数，即它基于输入参数执行一些计算，并且期望返回该计算的结果，则返回类型很明显。

有两个，当一个人之间的灰色地带可能决定从该方法返回一些“额外”的信息，如果它被认为是有用的为它的调用者。就像您的示例中有关插入中受影响的行数的示例一样。或者对于将元素放入关联集合的方法，返回与该键关联的先前值（如果有的话）可能很有用。可以通过仔细分析API的（已知和预期）使用方案来识别此类使用。

彼得的答案很好地涵盖了例外情况。这里的其他考虑还涉及命令查询分离

CQS原则说，方法应该是命令或查询，而不是两者。命令永远不要返回值，只能修改状态，查询应该只返回而不修改状态。这样可以使语义非常清晰，并有助于使代码更具可读性和可维护性。

有少数情况是违反CQS原则是一个好主意。这些通常围绕性能或线程安全性。

无论走什么路，您都将沿着这个道路走。那里没有返回值以备将来使用（例如，函数总是返回true），这是非常浪费的工作，并且不会使代码更清晰易读。当您有返回值时，应该始终使用它，并且要能够使用它，您至少应具有2个可能的返回值。

我曾经写很多void函数。但是，由于我掌握了整个方法的链式破解方法，因此我开始返回此方法而不是返回void －最好还是让某人利用该返回值，因为您无法蹲空。而且，如果他们不想对此做任何事情，则可以忽略它。