Is error handling required in business logic? eg. Zero check / percentage limit check, etc.
We usually do unnecessary checks in our business logic to avoid crashes.
Eg.
1. public ObjectABC funcABC(){
ObjectABC obj = new ObjectABC;
..........
..........
//its never set to null here.
..........
return obj;
}
ObjectABC o = funABC();
if(o!=null){
//do something
}
Why do we need this null check if we are sure it will never be null? Is this good practice or not?
2. int pplReached = funA(..,..,..);
int totalPpl = funB(..,..,..);
funA() just puts a few more restriction over result of funB().
Double percentage = (totalPpl==0||totalPpl<pplReached) ? 0.0 : pplReached/totalPpl;
Do I need to 'totalPpl<pplReached'
check?
The question arises: are we not swallowing some fundamental problem by setting such checks? Ideally, questions that should be shown can be avoided by placing these checks.
What's the recommended way?
source to share
Think about your audience. The check is worth when it
- helps you, the programmer, to find errors,
- helps other programmers to spot bugs where their code matches yours,
- allows the program to recover from an incorrect input or invalid state, or
- helps the maintainer avoid mistakes later.
If your tag null
above does not apply to them, or there is a simpler mechanism that would do the same, then leave it.
Simpler mechanisms often include
- unit tests.
- annotations that communicate intent to the reader and can be checked by findbugs or similar tools
-
assert
that cause the code to crash at the beginning and communicate intent without requiring you to enter error handling code that should never be reached and without obfuscating the code coverage tools. - documentation or inline comments
In this case, I would suggest adding the annotation
public @Nonnull ObjectABC funcABC(){
integrating findbugs into your build process and possibly replacing
if(o!=null){
//do something
}
from
assert o != null: "funcABC() should have allocated a new instance or failed."
Are we not swallowing some fundamental problem by putting such checks?
Usually,
- unit tests are good for testing the behavior of a small piece of code. If you cannot write unit tests for important functions, then the main problem is that you are not writing test code .
- annotations are good for communicating intent to code browsers, maintainers, and automated tools. If you haven't integrated these tools into your process, the main problem is that you are not using the available code quality tools.
-
assert
good for double-checking your assumptions. If you can't sprinkle assertions into your code and quickly report which ones are broken, your main problem is that you don't have a quick code run from representative data to get rid of the problems. - The documentation and inline comments (including comments on the control source) are useful for spreading knowledge about the system among the team - make sure more than one person on the team can fix the problem in any part of the code. If they are constantly missing or out of sync, then the main problem is that you are not writing code with supporting devices.
Finally, design by contract is a programming methodology that many find useful for business logic code. Even if you can't convince your team to adopt specific tools and techniques, reading up on DbC can help you understand and explain how to enforce important invariants in your codebase.
source to share