方法返回类型
在我的公司，系统被设计为三层。 Layer1负责业务逻辑处理。 Layer3 正在调用后端系统。 Layer2 位于两层之间，因此 Layer1 不需要了解后端系统。为了中继来自第 3 层的信息，第 2 层需要定义到第 1 层的接口。
例如，layer1 想要检查用户的 PIN 是否正确。它调用layer2 checkPin()方法，然后layer2调用相关后端系统。 checkPin() 结果可能是： CorrectPin、inCorrectPin 和 InternalError。目前，我们定义了返回类型“int”。所以如果layer2返回0，则表示正确的Pin；如果返回1，则表示inCorrectPin；如果返回 9，则表示内部错误。
有用。但我对这种做法感到有点不安。有更好的方法吗？例如定义一个枚举CheckPinResult{CORRECT_PIN,INCORRECT_PIN,INTERNAL_ERROR}，并返回CheckPinResult类型？
谢谢， 莎拉
In my company, a system is designed to have 3 layers. Layer1 is responsible for business logic handling. Layer3 is calling back end systems. Layer2 sits between the two layers so that layer1 doesn't need to know about the back end systems. To relay information from layer3, layer2 needs to define interface to layer1.
For example, layer1 wants to check if a PIN from user is correct. It calls layer2 checkPin() method and then layer2 calls the relevant back end system. The checkPin() results could be: correctPin, inCorrectPin and internalError. At the moment, we defined the return type 'int'. So if layer2 returns 0, it means correctPin; if 1 is returned, it means inCorrectPin; if 9 is returned it means internalError.
It works. However I feel a bit uneasy about this approach. Are there better ways to do it? For example define an enum CheckPinResult{CORRECT_PIN,INCORRECT_PIN,INTERNAL_ERROR}, and return CheckPinResult type?
Thanks,
Sarah
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我喜欢枚举方法。它是自记录的并且易于扩展。您可以设置每个返回的值以匹配您已有的 0、1、9 约定。
抛出异常当然是一种合理的方法，但抛出异常可能是一件昂贵的事情。我一直认为它们应该用来表示真正的特殊情况。引脚不良可能会也可能不会那么特殊，具体取决于您的业务问题。如果您的流程允许引脚具有“五个九”的可靠性，那么我想说，例外将是一个好方法。
但如果故障率在 1% 左右，我认为返回值可能会更好。您可能想要循环遍历大量值，并简单地将具有失败引脚的零件号累积为一个大批次。这取决于您如何使用错误代码。
I like the enum approach. It's self-documenting and easily extensible. You can set the value returned by each one to match the 0, 1, 9 convention you have in place.
Throwing an exception is certainly a defensible approach, but throwing exceptions can be an expensive thing. I've always believed that they should be used to indicate truly exceptional situations. Having a bad pin may or may not be that exceptional depending on your business problem. If your process allows "five nines" reliability for pins, then I'd say that an exception would be a good way to go.
But if failure rates are more on the order of 1%, I'd say that a return value might be better. You might want to loop through a large lot of values and simply accumulate the part #s with failed pins as a large batch. It depends on how you use the error code.
您收到内部错误是合理的常见情况吗？如果没有，我会让
checkPin返回一个布尔值，并在存在内部错误时抛出异常（但随后我可能会调用方法pinIsValid或类似的方法）。如果它（由于某种原因）是遇到内部错误的预期结果，那么三态枚举可能会很好地工作（我当前的项目中有类似的情况）。
Is it a reasonable common case that you get the internal error? If not, I would have
checkPinreturn a boolean and throw an exception if there is an internal error (but then I'd probably call the methodpinIsValidor something like that instead).If it (for some reason) is an expected result to encounter the internal error, then a tri-state enum could probably work out well (I have a similar case in my current project).
枚举无疑是对整数返回类型的改进，也是一种完全有效的方法。另一种选择是使用第 2 层签名，例如：
既然我认为内部错误是例外，为什么不这样对待它们呢？
Enum is certainly an improvement over integer return types and a perfectly valid approach. Another option would be to have a layer 2 signature such as:
Since, I presume, internal errors are the exception, why not treat them as such?
这是一个风格问题。您所描述的方式是一种实现目标的 C 风格。 java 风格如下： checkPin(pin) 应该返回一个布尔值。 True 表示引脚正常，False 表示引脚不正常。如果发生错误，您将抛出异常。异常是 Java 中处理错误的标准方式。异常很有用，因为它们可以具有类型和错误消息来帮助调试。
我说您描述的机制是 C 风格，因为在 C 中，处理错误的标准方法是返回映射到定义的整数，然后通过引用传入您要查找的值（在本例中为布尔值） 。因此，在 c 中，无论
哪种方式，我强烈建议不要在返回布尔值的同一位置返回错误值。这会造成混乱，因为单个值（返回值）实际上应该只代表一件事。错误状态和问题的答案是两个不同的东西，因此应该通过不同的渠道返回。
我希望这有帮助。
This is a question of style. The way you described is a sort of C style to accomplish the goal. The java style is the following: checkPin(pin) should return a boolean. True meaning the pin is ok and false meaning it is not ok. If an error happens you throw an exception. Exceptions are the standard way of dealing with errors in Java. Exceptions are useful because they can have types and error messages to aid in debugging.
I say that the mechanism you are describing is a C style because in C the standard way to handle errors is to return an integer that maps to a define and then pass in by reference the value you are looking for (in this case a boolean). So in c you would have
Either way, I strongly recommend not returning the error value in the same place that you return the boolean. This creates confusion because a single value (the return value) should really only represent one thing. The error status and the answer to the question are two different things and so should be returned through different channels.
I hope that helped.