When Firefox tried to make the "X is undefined" JavaScript exception message user-friendlier, it broke flipkart.com. The website's JavaScript explicitly depended on the exact wording of exception messages. Simply loading the flipkart.com home page caused "X is undefined" exceptions, which it tried to parse with regular expressions. The new exception message had to be reverted. :(<p><a href="https://www.fxsitecompat.com/en-CA/docs/2018/improved-javascript-error-message-breaks-code-relying-on-the-legacy-format/" rel="nofollow">https://www.fxsitecompat.com/en-CA/docs/2018/improved-javasc...</a><p>This is an unfortunate example of Hyrum's Law: "With a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody."<p><a href="http://www.hyrumslaw.com/" rel="nofollow">http://www.hyrumslaw.com/</a>
In JavaScript I often find my self running the code in both firefox <i>and</i> chrome to get the full picture of <i>what is undefined</i>: (firefox)<p><pre><code> window.foo.bar
//=> TypeError: window.foo is undefined
</code></pre>
and <i>what I'm trying to get</i>: (chrome)<p><pre><code> window.foo.bar
//=> Uncaught TypeError: Cannot read property 'bar' of undefined
</code></pre>
Personally I find the firefox error message more useful, but often I get a better understanding of whats wrong when I run it in chrome. I don’t know why they are mentioning undefined at all and don’t say something like:<p><pre><code> TypeError: Cannot read property 'bar' of 'window.foo' (undefined)
</code></pre>
---<p>Edit: Formatting
This sounds like a good addition.<p>It happens quite often that we get a bug report with "We got a NPE". Our users often attach a screenshot, just showing the standard "NPE error" message, which does not really help.
> Computation overhead
> NullPointerExceptions are thrown frequently.<p>"Frequently" is obviously a relative term, but are NullPointerExceptions really common enough to be a performance concern? It's good that they are taking performance overhead into consideration of course, I'm just surprised it's even an issue.
This would be good, but I'd prefer that Java have something like the null operators that C# has.<p><a href="https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operators" rel="nofollow">https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...</a>
Funny thing, some JVM's already do exactly this for many years:<p>Failed to write HTTP message: org.springframework.http.converter.HttpMessageNotWritableException: Could not write JSON: while trying to invoke the method de.hybris.platform.catalog.model.CatalogModel.getId() of a null object returned from de.hybris.platform.catalog.model.CatalogVersionModel.getCatalog();
I am not really that familiar with Java, but I don't understand how to get a JVM heap dump if there is an exception that brings down the JVM or even a thread. Is it even possible?<p>I work on mainframe (z/OS), and it is completely normal there that when an application fails with exception (they're called ABENDs - from ABnormal ENDing), you can get a dump of memory of the application. From that, you can see all the values of the offending variables and all the relevant system areas and so on.
After 20 years, first in Java and then in Scala I've been tortured by this error message. Some years ago they fixed ClassCastException which for a long time also didn't tell you what was wrong. There are some others if I remember correctly with bad error messages, like NumberFormatException. In general error messages on the JVM are very bad, wish they would take a look at Elm error messages.<p>I've left this year the JVM for TS, but glad for everyone who uses the JVM.
It is almost 2020 so it is reasonable to know what the actual error is.<p>This reminds me of old C/C++ parsers that couldn't tell you what line was expecting a bracket or semicolon and you got to manually find the parse error.
This is awesome! I ran into this exact issue yesterday evening trying to debug a NPE on foo.bar().baz().hello()<p>IMO overhead should not even be a consideration. It doesn't make sense to sacrifice detailed reporting just so someone can repeatedly handle NPEs as part of their application's logic. I can't imagine a situation in which I would look at code that throws enough NPEs for overhead to be a concern and say "yes this is well designed code"
This is too much of a hack; I predict it will be unreliable, at times sending programmers on wild goose chases more time-wasting than an uninformed investigation.
I wonder if it's possible to add something similar to the protection you get in Haskell to other languages via some static analyzer or something.<p>In Haskell, it's pretty much impossible to have unexpected nulls because the ability to return nulls is something that is expressed in the type and needs to be handled before working with the possible type to be able to pass the type-check of the compiler.<p>For example, if I had a function:<p><pre><code> findFistOdd :: [Int] -> Maybe Int
</code></pre>
That returned the first odd number in a list of numbers, the Maybe wraps the return value so the result is either `Nothing` or `Just someNumber`. I can't work with the result directly like<p><pre><code> 1 + findFirstOdd [2,3]
</code></pre>
It would fail the type check, because I need to tell the compiler what the program should do if findFirstOdd couldn't find an odd number. (1 +) is certainly not expecting a NULL as its argument type is Int. I can tell it, "Just die if that happens":<p><pre><code> 1 + (fromMaybe (error "couln't find odd number") $ findFirstOdd [2,3])
</code></pre>
or I can tell it to work on the inside value if it's there, returning Just (1 + someOddNumber) if it's there or Nothing if it's not:<p><pre><code> (1 +) <$> findFirstOdd [2,3]
</code></pre>
Conversely, if a function says it returns an Int:<p><pre><code> addOne :: Int -> Int
</code></pre>
That means it returns an Int, guaranteed. That's never going to be some null value. It's not something you'd ever have to consider.<p>Kind of wish all languages were like this. Nulls are probably the cause of most unexpected exceptions and it could be something that could always be caught without even running the program.
> Given the bytecode, it is not obvious which previous instruction pushed the null value. To find out about this, a simple data flow analysis is run on the bytecodes.<p>This is a petty nit on what sounds like some great work but please do not use the word "simple" in technical contexts like this. Having you assert that it is simple does not make it easier for anyone to understand, and it is really quite irritating. I don't even know what "data flow analysis" is and I've been involved with computer programming and data analysis for 15 years.
Interesting, so they want to go beyond the line number of the exception and include information on what on the line is null.<p>It's sort of funny that their example doesn't follow the usual Java style guidelines of encapsulating member variables in the parent and using set() and get() methods for access.<p>a.to_b.to_c.to_d.num = 99;<p>This could be rewritten as a method in 'A' as...<p>protected void setDNum(int num) {<p><pre><code> C c = b.getC();
D d = c.getD();
d.setNum(99);
</code></pre>
}<p>In this case, a nullpointerexception would include the line number (using default compiler options) clearly indicating which is null.
>As computing the NullPointerException message proposed here is a considerable overhead, this would slow down throwing NullPointerExceptions.<p>You could lower the overhead by not producing these messages if the exception is thrown frequently. It would be similar to the existing OmitStackTraceInFastThrow mechanism [0].<p>[0]: <a href="https://www.oracle.com/technetwork/java/javase/relnotes-139183.html" rel="nofollow">https://www.oracle.com/technetwork/java/javase/relnotes-1391...</a>
I don't see that many NPE in kotlin these days but pretty sure that on java/Android I get a useful error message.<p>Is that an ART/Dalvik feature ?
Java is pretty weird land. It's 2019 and there's still this issue with Nullpointer Exception and the other big limitation is that you cannot create a new instance of a generic type in a generic function, making programs dynamic, like in C++. Funny, because the whole JVM is based on C++
I'm a bit torn on this because I always avoided having too many method calls on the same line. Code Complete recommended this a long time ago.<p>However now I see just about everyone stacking this method calls one after the other. Is this just acceptable now?<p>state = stateFromPostcode(customer.getAddress().getPostCode());
I don't write Java, but support an application written in Java that gets null pointer issues and aborts all the time. It's also annoying that there is precious little information for me to go on.
I hope I'm not the only one who read the title as adding some helpful text to the exception for n00bs, which explains about the very concept of null.
Other than supporting and working with legacy software, I cannot muster any reason to write code in Java at this point... it’s just a terrible language to work with.