About the handling of Null

I think that many people may find null checking annoying when touching the development language. I think it's normal to see the existence of null objects, but to be honest, I think it's awkward to wrap even if you look at auto_ptr in C ++ / stl and Optional in java. Under such circumstances, I am very happy to try to eliminate null at the language level like kotlin.

So, I'd like to consider how to write code that does not encounter null, so I will write down what I care about for the time being

** Why do you hate null? ** **

The most disliked part of null is if (null === I think that the context is described as a context that has nothing to do with business logic. Therefore, I am thinking about how beautifully various people can be summarized only in business logic.

** Wrapping case as a common null avoidance method **

First, try collecting general null avoidance methods as far as you are interested

*** Return value of Collection ***

*** There is no need to perform null check like if statement, so there is no sense of discomfort in business logic *** List/Array/Map In SQL etc., if there is no data when getting the result, null may be returned. By using List, Array, etc. as the return value, null check can be eliminated or the number of items can be checked.

*** Optional *** and *** std :: auto_ptr ***

*** Instead of null check, substitute processing is inserted, but surrogate value can be entered in one statement, so the sense of incongruity in business logic is lessened *** std::auto_ptr In C / C ++, the operator operator can be used, so it can be used without discomfort depending on the application.

 int* pint = ptr.get();
```Etc., there is a problem of ownership etc. and it is necessary to pay attention to the implementation method

[Optional](https://docs.oracle.com/javase/jp/8/docs/api/java/util/Optional.html)
 Even though I want to use an object, it feels strange to call a method because it is wrapped.
 I've heard that it's always used only as a return value, but I think it's awkward to receive it as a return value and substitute it anew.

## *** Reactive Mono / Flux ***
 *** There is no need to perform null check like if statement, so there may be no discomfort in business logic ***
 [mono](http://projectreactor.io/docs/core/release/reference/#mono)
 It says "Issue one item at most", but intentionally wraps it with only 0 .. 1.
 [flux](http://projectreactor.io/docs/core/release/reference/#flux)
 It says "0 to N items" and intentionally represents 0 .. N.

# ** Cases where null conditions are not described, such as NullObject **
## *** Existence of exception and try / catch ***
 Recently, by using exception and try / catch, segmentation fault etc. caused by nullpo has disappeared, so it may be said that you do not have to worry about null object.

## *** If there is no exception ***
 When null check is not performed, memory leaks occur frequently and may cause unintended behavior.
 Therefore, it is necessary to perform appropriate error handling after null check.

 ***null object***
 When returning an object, returning a type other than object (null) will result in an unintended branch, but if a single object is returned, the logic can proceed smoothly.
 However, since it is necessary to return a reasonable behavior or exception in all methods, it may be more straightforward to throw a NullPointerException normally nowadays on the premise of try / catch.