Method Return Type

Question

In my company, the system is designed for 3 levels. Layer1 is responsible for handling business logic. Layer3 invokes reverse systems. Layer2 is between two layers, so layer1 does not need to know about the back systems. To pass information from layer 3, layer2 must define an interface for layer1.

For example, layer1 wants to verify the correct PIN from the user. It calls the layer2 checkPin () method, and then layer2 calls the corresponding back system. The results of checkPin () can be: correctPin, inCorrectPin and internalError. At the moment, we have defined the return type 'int'. Therefore, 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 am a little worried about this approach. Are there any better ways to do this? For example, define the enumeration CheckPinResult {CORRECT_PIN, INCORRECT_PIN, INTERNAL_ERROR} and return the type CheckPinResult?

Thanks Sarah

Answer 1

I like the enum approach. It is self-documenting and easy to expand. You can set the value returned by each of them in accordance with the agreement you accepted 0, 1, 9.

Throwing an exception is certainly warranted, but an exception can be costly. I have always believed that they should be used to indicate truly exceptional situations. Having a bad pin may or may not be so exceptional depending on your business problem. If your process provides “five nines” reliability for contacts, I would say that an exception would be a good way.

But if the number of failures is greater than about 1%, I would say that the return value may be better. You might want to scroll through a large number of values ​​and simply accumulate the # part with the failed outputs as a large batch. It depends on how you use the error code.

Answer 2

Is it a reasonable common case that you get an internal error? If not, I would checkPin return a boolean and throw an exception if there is an internal error (but then I would probably call the pinIsValid method or something like that).

If this (for some reason) is the expected result to meet an internal error, then renaming the tri-state could probably work well (I have a similar case in my current project).

Answer 3

Enum, of course, is an improvement over whole return types and a perfectly correct approach. Another option would be to have a level 2 signature, for example:

 public boolean isPINValid() throws InternalErrorException(); 

Since, I believe, internal errors are an exception, why not treat them as such?

Answer 4

This is a matter of style. The way you described is a kind of C style to achieve the goal. The java style is as follows: checkPin (pin) should return a boolean value. The true value of the pin is normal, and false means that it is not normal. If an error occurs, you are throwing an exception. Exceptions are the standard way to fix bugs 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 matches the definition and then pass the value you are looking for (by boolean). So in c you would

 int checkPin(int pin, bool &ans); //returns an error value. 

In any case, I highly recommend not returning the error value in the same place where you are returning the boolean value. This creates confusion because a single value (return value) should really represent only one. The error state and the answer to the question are two different things, so they need to be returned through different channels.

I hope this helps.