在我的公司，一个系统被设计为有3层。 Layer1负责业务逻辑处理。 Layer3是呼叫后端系统。 Layer2位于两层之间，因此layer1不需要了解后端系统。为了传递来自第3层的信息，第2层需要定义接口到第1层。方法返回类型
例如，层1要检查是否从用户PIN码是正确的。它调用layer2的checkPin（）方法，然后layer2调用相关的后端系统。 checkPin（）结果可能是：correctPin，inCorrectPin和internalError。目前，我们定义了返回类型'int'。所以如果layer2返回0，这意味着correctPin;如果返回1，则表示inCorrectPin;如果返回9，则意味着internalError。
它的工作原理。不过，我对这种方法感到有些不安。有没有更好的方法来做到这一点？例如定义一个枚举CheckPinResult {CORRECT_PIN，INCORRECT_PIN，INTERNAL_ERROR}，并返回CheckPinResult类型？
感谢， 萨拉
我喜欢枚举方法。它是自我记录并且易于扩展。您可以设置每个返回的值以匹配您已有的0，1，9惯例。
抛出异常肯定是站不住脚的做法，而是抛出异常可以是一个昂贵的事。我一直相信他们应该被用来表明真正的特殊情况。根据您的业务问题，使用不良引脚可能会或可能不会那么特殊。如果你的程序允许针对“五个九”的可靠性，那么我会说，一个例外将是一个好方法。
但如果失败率更的1％左右，我会说，返回值可能会更好。您可能想要循环使用大量值，并简单地将具有失败引脚的部分＃作为大批量进行累加。这取决于你如何使用错误代码。
我们的建筑师肯定会同意你的意见。他根本不喜欢Java异常机制。 – sarahTheButterFly
可悲的是我无法说服我的同事使用枚举。他们说这是过多的重新分解工作。 :( – sarahTheButterFly
我们正在讨论改变单一方法的签名，对吗？如果是这样的话，对于像IntelliJ这样的工具来说很容易。你调用这个方法多少次？我也不会接受很多“，没有一些可以量化的证据来支持它 – duffymo
难道你得到的内部错误一个合理的常见的情况？如果没有，我会让checkPin返回一个布尔值，并在出现内部错误时抛出异常（但我可能会调用方法pinIsValid或类似的东西）。
如果（由于某种原因）是预期的结果，遇到了内部错误，那么三态枚举很可能进行得很顺利，（我在我的当前项目类似的情况）。
枚举肯定是在整数返回类型和一个完全有效的方法的改进。另一个选择是有一个第2层签名，如：
public boolean isPINValid() throws InternalErrorException();
因为，我认为，内部错误是例外，为什么不把它们当作这样呢？
这是一个风格问题。你描述的方式是一种C风格来完成目标。 java风格如下：checkPin（pin）应该返回一个布尔值。真正的意思是指针是好的，假的意思是不好。如果发生错误，则抛出异常。例外是Java中处理错误的标准方法。例外是有用的，因为它们可以有类型和错误消息来帮助调试。
我说你描述的机制是C风格，因为在C中，处理错误的标准方法是返回一个映射到一个定义的整数，然后通过引用传入你正在寻找的值（在这个情况下布尔）。所以，在C你会
int checkPin(int pin, bool &ans); //returns an error value.
无论哪种方式，我强烈建议不要返回在返回布尔同一个地方的误差值。这会造成混淆，因为单个值（返回值）应该只代表一件事。错误状态和问题的答案是两个不同的东西，所以应该通过不同的渠道返回。
我希望有所帮助。
哈哈..你明白了.C风格。我的同事定义了接口是从C背景开始的。说服来自C背景的人使用enum。 – sarahTheButterFly
在每个图层上使用例外。如果一个图层失败，您会捕获该异常。这样，你就知道哪一层失败了。这是一个建议，所以我没有把它作为答案。 –
是的，我明白你的观点。我们目前正在做的是在发生内部错误时记录错误。如果出现异常，我们将其捕获并记录在layer1中。 Layer2和Layer3将其升级到更高层。 – sarahTheButterFly
我认为Elite所说的是从每一层创建一个自定义异常。这些是商业例外，这是我们所做的。当你将图层用作API时，它也会有所帮助，外部开发人员将能够处理这些错误。 –