返回值：布尔值vs int标志与异常

我需要定义一组函数作为面向公共SDK的接口的一部分，并试图找出发送给调用者代码的最佳方式，如果某件事情成功或不成功如果没有，为什么不呢。返回值：布尔值vs int标志与异常

我的第一个考虑是返回值与异常。我想我需要结合使用这两者。由错误导致的错误状态/错误的例外。返回值用于函数按预期方式运行并且只是将调用结果返回给调用者的时间。

现在，为返回类型。我可以使用int（标志）或布尔值。内部认为应该使用布尔值，因为它更简单，并且不需要标志。布尔人限制你指定成功或失败，而没有解释。

我会使用两个标志来代替标志。首先，您可以返回两个以上的可能值。允许{success，fail，fail_reason_1，fail_reason_2，fail_reason_3}。请注意，因为这是用于各种硬件设备上实现的接口，所以可能需要能够通知操作失败的原因。例如连接的设备不支持嘟嘟声，没有LCD，不支持嵌入式加密等。

谁知道未来需求是什么。返回一个布尔现在锁定你，而使用标志可以让你在未来有更大的灵活性。那么，如果将来你永远不需要两个以上的价值。至少你有选择。

考虑到这将是一个面向公众的SDK我希望尽可能多的灵活性以防止未来发生突变。

感谢

来源

2014-03-31 conor

java.lang.Enum？ – esej

除了成功，我只看到多种类型的失败。为什么这些不能包含在例外中？ – nablex

枚举或int标志。还有同样的问题。失败可能是半预期的。即操作不受支持。异常会改变流程，我的理解只能用于异常/意外状态。 – conor

在我看来返回一个值来表示一个方法调用的结果，并抛出一个异常是一个值仅仅是一个发生了什么通知之间的差异。该方法调用应视为已成功执行它所定义的合同。例如，看看如何定义boolean : Set.add()。

如果某个方法抛出一个异常，这应该表示在对象/整个系统处于非法状态时方法的不正确使用或调用。例如，当他的帐户没有足够的积分时，试图为用户购买某物。

一个异常非常适合捕获不同的故障类型：或者通过异常层次结构或向异常中添加属性，如getFailureCode()或将它们组合在一起。

我不使用标志，以表明故障状态的故障必须处理。因为忽略返回值很容易，程序员可能会忽略它，而异常则必须被忽略。

来源

2014-03-31 07:49:15 Harmlezz

简短的回答是，它根据您的域名，客户以及您提供的具体情况而有很大差异。如果你还没有，你需要坐下来与你的客户，并找出他们将如何使用图书馆。刚刚离开我的头顶，这里有一些我会考虑的事情：

首先，您确定的所有故障类型基本上是相同的东西 - UnsupportedOperationException，原因是什么。是否有其他故障类型？如果不是，并且您使用异常，则可能需要一个类型为/ cause/whatever的异常类作为枚举属性。其次，它看起来很多/大多数/所有的方法将会有一个或多个类似的失败类型。真的吗？如果是这样，您的API是否提供了确定设备支持哪些功能的方法？试想一下：

// Best if I probably don't care about the result if it's not SUCCESS 
final Result result = myApiObject.someMethod(); 
if (result == Result.BEEP_UNSUPPORTED) { 
.... 
} else if (result == Result.NO_DISPLAY) { 
.... 
} else if ...

这：

// Best if I have to handle every possible failure condition, and I care what 
// the failure type is 
try { 
    myApiObject.someMethod(); 
} catch (final BeepUnsupportedException e) { 
.... 
} catch (final NoDisplayException e) { 
.... 
}

这：

// Best if I have to consider every possible failure condition, but it probably 
// doesn't matter what the failure type is 
try { 
    myApiObject.someMethod(); 
} catch (final MyApiException e) { 
    if (Cause.BEEP_UNSUPPORTED == e.getCause()) { 
     .... 
    } else ....

这：

// Best if I know in advance what features I may need 
// someMethod() may still return response codes or throw an exception. In this case 
// it's possibly OK to make it a RuntimeException, since clients are expected to 
// poll for features. 
if (myApiObject.supports(Feature.BEEP) 
     && myApiObject.supports(Feature.DISPLAY)) { 
    myApiObject.someMethod(); 
} else ...

哪一个是最接近的方式你的客户会想要使用你的系统？

三，这些错误有多致命？我完全同意@Harmlezz必须处理的故障必须是异常。没有更多的信息，我们谁都不能告诉你，你的失败是否需要处理。如果客户大多会忽视失败（他们通常希望代码失败），或者只是主要关心SUCCESS或!SUCCESS，那么返回代码可能没问题。如果故障需要来处理，那么你应该抛出一个检查异常。您可能希望远离未经检查的异常，因为这些失败不是编程错误，并且可能由客户端正确处理。

来源

2014-03-31 18:42:01

返回值：布尔值vs int标志与异常

回答

相关问题