Optional use of simple and can not solve business problems in the NPE

Work often encounter NPE (NullPointException) how to deal with the problem, get most of the answer is Optional to deal with, but simply use Optional and can not solve NP problems in business . So sorting out the idea of daily work process NPE problem for reference.

Look at ideas:

01 Avoid operation

Avoid the use of Optional parameters 01.01

Daily work there is to see the following code.

public void execute(Optional<String> nameOptional) {
   ...
}
复制代码

If a parameter method may be null, you can use method overloading, instead of passing a null. Because the business intent on revealing the code to achieve better than only that business intent, because business is not null business sense, if the null occur, but need to be addressed related logic, you can use method overloading.

In addition, the method call will act very clear parameters do not need to call a method constructed Optional.

public void execute() {
     execute(null);
}

public void execute(String name) {
    ...
}
复制代码

The above code to avoid vague intention of external methods, but also to avoid duplication of code sections.

01.02 Avoid multiple lines if () statement

"Using the Optional, I did not feel logical change change simple ah, each had to get () method", which is expressed developers work just contact Optional heard of.

Where is the problem? If we have a walnut clip, but each with it the Nutcracker to do is to drop walnuts, then find and there is no difference smashed with a hammer, the results are broken in one place.

When we say that the reconstruction of the code out, rather than designed. So when implemented to determine if the use of the Optional unfamiliar if, when you can try to reconstruct looking for something to have a better solution. Because the switch statement is inherently bad taste, look for direction can take a look Optional addition to providing a get method, which also provides a method, they are doing what purposes.

02 How do

02.01 use the return value Optional explicitly handled by

If the actual implementation, we need to return a null value, we can return a Optioanl objects back, so that the method caller must know that there is likely to return null, and subjected to specific treatment.

public Optional<Data> execute() {
    ...
	return Optional.empty();
}
复制代码

02.02 when appropriate use Exception

No results we can not only choose to return Optiona.empty (), unless the logic required to proceed without interruption expectations, or we can choose to directly throw.

For example, according to the username, password looking for a user, if the user is not found, you can directly throw InvalidUsernameOrInvalidPasswordException.

public User login(String name, String password) {
	...
	
	throw new InvalidUsernameOrInvalidPasswordException();
}
复制代码

Then, the outer layer or exception handling, or Project exception caught globally unified processing.

02.03 Use Optional Lambda

Optional methods mentioned because unfamiliar provided, and a null value is determined from feeling is not much difference in 01.02. It is recommended to select Optioanl Lambda wording based on business scenarios.

String name = computer.flatMap(Computer::getSoundcard)
	.flatMap(Soundcard::getUSB)
	.map(USB::getVersion)
 	.orElse("UNKNOWN");
复制代码

The above wording than the following wording much clearer. Of course, this requires curiosity, a little more than learning tools provided, but do not always make easy work of moving bricks.

String version = "UNKNOWN";
if (computer != null) {
	Soundcard soundcard = computer.getSoundcard();
	if (soundcard != null) {
		USB usb = soundcard.getUSB();
		if (usb != null) {
			 version = usb.getVersion();
 		}
 	}
}
复制代码

reference

02.03 The final source code