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
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.