All those NPEs

| | bookmark | email
This weekend I have passed some time checking the code generated by dtoGen™. I have been trying to remove any possibility that a NPE would occur in the generated tool class. (for those not knowing about dtoGen I would recommend a quick read of the intro). I have had to check against NPEs for any instance forced convertor (something like model.getValue().intValue()). I have had to check against NPEs for collections, arrays, maps manipulation... and at a moment I got angry on these NPEs. Why should I check it and not the compiler? (hmmm wait a minute is this possible? would it be fesable? would it be really good?). I sat down for a moment and thought of this. How easy would life be without NPEs! But no, this is not true. The compiler should create check points for any instance variable access or for any instance method call. The code will grow over and over. This is not the last issue. What would it happen when a possible NPE occur? Just signal you? Ignore that piece of code? Wow... after object oriented programming we would begin the fuzzy programming era. I would go home and say: I wrote down today a program. There are many chances it will run. But also many chances it will go a path I don't even imagine it can. So, bye bye swearing NPEs. They are a good evil!