On Thu, 5 Mar 2020 at 19:29, Gilles Sadowski <gillese...@gmail.com> wrote: > > Le jeu. 5 mars 2020 à 16:12, sebb <seb...@gmail.com> a écrit : > > > > On Wed, 4 Mar 2020 at 14:20, Gilles Sadowski <gillese...@gmail.com> wrote: > > > > > > Le mer. 4 mars 2020 à 15:16, sebb <seb...@gmail.com> a écrit : > > > > > > > > On Wed, 4 Mar 2020 at 14:09, Gary Gregory <garydgreg...@gmail.com> > > > > wrote: > > > > > > > > > > IMO, until we are all on Java 14 and benefit from its more detailed > > > > > NPE > > > > > message, we need to call Validate.notNull _with a message_ that says > > > > > what > > > > > variable blew up. > > > > > > > > +1 > > > > > > > > That is another good point. > > > > > > > > Unless one has access to the exact same version of the source, it can > > > > be very tricky to tell which variable has caused the NPE. > > > > The same applies to letting the JRE throw the NPE. > > > > > > Are you assuming that one should be able to fix the bug > > > without the stack trace? > > > > No, I'm saying that the stack trace is not much use without having > > access to the exact version of the source that was used to create the > > binary. > > An approximate line number may not be sufficient to identify the variable. > > > > > If so, I fail to see how having the name of a variable will > > > make it less tricky to locate the cause of the issue... > > > > See above. > > I'm not trying to prove that less information is better. > > However without the exact source, having the exact > name of the variable is similarly of not much use.
Huh? The stack trace shows the name of the method in which the problem occurs. If the exception shows the name of the variable, that uniquely identifies it, even if the exact source is not known. > IOW, with the exact source and in the case where > the variable is used by the method itself, the stack > shows exactly where the unexpected null occurred. Of course, but the exact source may not be known. > Moreover, if the null occurred because of a user error > (e.g. missing configuration directive), the link with the > variable name may not be obvious. That is not relevant here. > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
