• Post Reply Bookmark Topic Watch Topic
  • New Topic

NPE Null Pointer Exception  RSS feed

 
Ranch Hand
Posts: 434
7
Android Open BSD Slackware
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
in Java 8 is possible to use Optional to avoid NPE, in Kotlin and other languages is possible to exclude the NPE. People say that is the 1 bilion bug. Still I do not understand why is considered to be an error made by the team that created Java.
If I have an object that is null at runtime and is calling a method, I am happy to see a NPE, right? In this way I can identify the line of code and identify why the Object is null, maybe some refactoring, maybe some mistake, but is helpful.

So I cannot catch why NPE is measured as a problem and not an help for the programmers
http://www.oracle.com/technetwork/articles/java/java8-optional-2175753.html

According to my intuition is to use this kind of feature only when applying a NPE does not cause direct damage to the code execution, let's say when is redundant, is that correct?
thanks
 
Marshal
Posts: 56607
172
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, a null exception usually represents an error which is why allowing nulls comes top of this list of ten errors. (While we are on about it, I challenge you to tell us which of those ten is incorrect.) It wasn't the designers of Java® who made a mistake by introducing null; it was an accepted part of programming before then. It was actually Sir Tony Hoare who admits to making that mistake in the design of Algol60, nearly sixty years ago.
You are mistaken to think that it is easy to correct an NPE; it is easy to find where the null is, but it is much more difficult to find the real error, which can be many hundreds of lines of code away or even in a different class. It is often in permitting nulls in setXXX methods or constructors, but nulls can travel from place to place. Earlier throwing of Exceptions might help reduce the risk. So Urma is right that nulls are a problem.
The Optional class was designed (I think) by Brian Goetz, who didn't intend it as a general means to avoid null. Urma makes a good point in that sort of article (I haven't read it, but I have a copy of his book), but there is controversy about that. Search our Java8 forum and you will probably find something useful there. I found three liekly threads: thread 1 thread 2 and thread 3. It can be difficult to use Optional to obviate all uses of null, particularly if frameworks cannot yet cope with Optional.

I think this discussion would fit better in a different location: moving.
 
Giovanni Montano
Ranch Hand
Posts: 434
7
Android Open BSD Slackware
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK, because of iniquitous personal time constraint duties,with your laudable permission let's split your insightful intervention in two parts, not before promising I am going to reply the second part not later than Monday evening:
1) 10 most common error challenge
2)Null Pointer Exception, aka NPE

1)Marvelous link, core Java is beautiful, allow me to say I fairly think the verbosity of this language is what make it attractive to me, especially for debugging reasons.  With some degree of regret I find unpleasant Android, that is definitely responsible for the TIOBE index Java supremacy, is averting more and more toward different paradigms, as JVM compatible languages, and also turbid, confused reactive open source patterns.
Anyway better to stop here to avoid endangering judgements from my side.

Going back to business  I found two kind of imperfections to spot out, the first and minor one is related to the fact that point 2 aka capitalization errors should be considered in position 2, where is explicitly said is "one of the most recurrent errors". Personally speaking even using VI, EMacs, Pico or MCedit, is such a consolidated habit to declare instance and local variables, methods with camel characters starting with low letters, that rarely i found in my not bread  development experience making this kind of mistake. Let alone using Eclipse or IntelliJ with their colored templates. Ostensibly accepted as true the previous phrase,  I hope the error in the 10 common errors page is related to point 6, aka `Confusion over passing by value, and passing by reference`  because is generally accepted, according to my internet researches, that Java should be considered ALWAYS pass by value. In fact even if you pass an array, a vector, or a string, to a function instead of a primitive, the address of the variable remains allocated in the same memory address, even if we pass a pointer( in this case an Object) to the method. In C++ would be different because the variable would effectively change, in Java no way.  Apart that, it was interesting to acknowledge the fact "The java.util.Date, and java.util.Calendar classes start their months with 0, but days start normally with 1" really a counter intuitive convention in my humble opinion. Maybe was  an open source lack of common intent in Open JDK classes.


2) Thanks for your patience and see you within 3 days.
 
Campbell Ritchie
Marshal
Posts: 56607
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Correct: Java® always supports pass‑by‑value only.
Now classes like LocalDate are available, you can (fortunately) forget about those dreadful classes Date and Calendar. There are other things in the ten commonest errors which are dubious. For example, it is an old website, so when you read about spelling errors in overridden methods, there is no mention of the @Override annotation. I think it didn't exist when that list of errors was written.
 
Sheriff
Posts: 4289
127
Chrome Eclipse IDE Java Postgres Database VI Editor
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've started using Optional in general development and I like it.  True, if can be clunky at times, but it forces me to think about situations where there will be nothing useful to work on.  Also, I think that is more expressive than
 
Giovanni Montano
Ranch Hand
Posts: 434
7
Android Open BSD Slackware
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
2) If we speak about Clean Code procedures, Optional is nice, as a readable null check. Although is questionable because I can read chinese and struggle with that if I know  it since few months, but if I am familiar it would be almost immediate to extrapolate a meaning from an ideaogram, almost as reading my native language, so if I see a well formatted code
couldBeNullWhateverVariable !=null
it can be really immediate understanding the intrinsic meaning. Even another objection over the verbosity of a null classical java check vs Optional<T>. In my opinion is not a funded one because every IDE todays has code templates, and magnificent autocompletion features.In fact just as the old list of errors you mention regarding @Override the methods are  today almost automatically populated, and with  IntelliJ lambda expression are automatically added to anonymous classes, and compile check are faster than ever, especially considering injection annotated frameworks.  Still I cannot put my self in the feet of the language developers  that wrote Java®, Pascal or whatever NPE language. What I infer from my personal limited experience is that there are a bunch of really usueful NPE exceptions, that if would not be trown would leave me without any clue about why a software is not working as expected. I definitly see your point Ritchie, sometimes I have xml GUI files bound to Java®,Kotlin and  the NPE in the stacktrace refer to internal SDK, and debugging NPE it can be really complex.
 
Campbell Ritchie
Marshal
Posts: 56607
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the only useful sort of NPE is that thrown intentionally. I think the following is bad code because it doesn't throw any Exceptions:-It can allow a null into your object, which can cause difficulties later on, but you are not aware of how the null got there. The following is good code because it does throw an Exceptions:-If a null gets there, you want to find out about it as soon as possible, and you also want a message explaining why the exception was thrown. That code would be better with a documentation comment, and you may wish to change the message. Maybe it would be better with this Java7 method, too:-The Unicode escape \u2019 means apostrophe: '
You may have code which can accept nulls, in which case the exceptions are unnecessary. But it is then necessary to use other techniques to keep the nulls under control.

[edit] Remove unnecessary semicolons.
 
Giovanni Montano
Ranch Hand
Posts: 434
7
Android Open BSD Slackware
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I see, really easy example but powerful. And shows the verbosity of Java® is a strength not necessary a weakness. If one wants the so called  `synthactic sugar`  just use a custom template. It is clear to me that there are ote®  reasons beyond the strange evolution of this language
 
Giovanni Montano
Ranch Hand
Posts: 434
7
Android Open BSD Slackware
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Giovanni Montano wrote:I see, really easy example but powerful. And shows the verbosity of Java® is a strength not necessary a weakness. If one wants the so called  `synthactic sugar`  just use a custom template. It is clear to me that there are ote®  reasons beyond the strange evolution of this language

Well I have to partially correct this expression, a code that allow less lines is faster to read, and this is a great advantage in code reviews
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!