Le jeu. 5 mars 2020 à 19:04, Peter Verhas <pe...@verhas.com> a écrit : > > 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.
And it was my sole point. I obviously agree that more info is nicer, and easier to maintain. Gilles > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
