Just my 2c: When you have an assertion in the code that throws an exception, be it NPE or IAE then your code is less prone to errors during maintenance. In that case, the assertion is there is the code, kind of documenting it. If the assertion is not there with the reasoning that the subsequent code is throwing an NPE anyway then later a code change may alter the behavior, which may not be desired, and/or followed by the documentation.
In my opinion, these assertions serve documentation purposes and are an exceptional example when the "shorter code is more readable" law does not apply. Also, Objects.requireNonNull has a version that can contain a nice message that is absolutely valuable for the caller. (I think, this was already discussed in detail.) The only reason I cannot argue with is performance if it was properly measured in the relevant desired use cases and the measurement proves that the assertions pose significant performance cost. Regards, Peter On Thu, Mar 5, 2020 at 4:12 PM sebb <seb...@gmail.com> wrote: > 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. > > > 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 > > -- Peter Verhas pe...@verhas.com t: +41791542095 skype: verhas
