I've just reviewed the PR, and I think it has a lot of issues (typos, wrong format types etc.) It also mixes different concerns.
As such, I am -1 to the PR as it stands. I also don't think the new class adds any value. AFAICT all it does is allow one to drop the text 'new ' and 'String.'. (at the cost of an extra import) On Thu, 5 Sep 2019 at 09:33, Gilles Sadowski <gillese...@gmail.com> wrote: > > Le jeu. 5 sept. 2019 à 02:50, Gary Gregory <garydgreg...@gmail.com> a écrit : > > > > On Wed, Sep 4, 2019 at 4:51 PM Xeno Amess <xenoam...@gmail.com> wrote: > > > > > Well, if you do think repeating the similar codes for 100+ times is > > > better than reflection and be more elegant or easier to read or > > > something, then you can try maintain them. > > > There is 100+ Throwable classes who have string constructor in JDK IMO. > > > And don't forget some of them might only be in some certain versions > > > of JDK, and be careful about making them compilable on other version > > > of JDKs. > > > Also you might try to use some preprocess way to generate such > > > classes, some ways like lombok do (although that might be > > > controversial). > > > > > > > Allow me to repeat, perhaps rephrase, and elucidate any miscommunication > > based on what I said in the PR here: > > https://github.com/apache/commons-lang/pull/450#issuecomment-527892606 > > > > I am _not_ suggesting to apply this pattern to 100+ exception classes, > > ever. This is really an ever stricter application of the YAGNI and 80/20 > > rules. Both this idea and Commons Lang do not intend to provide this kind > > of comprehensive coverage. This PR is for one exception and eats its own > > dog food by refactoring 52 existing call sites within Commons Lang to use > > the new methods. I then suggested the same could applied for > > NullPointerException (7 possible call sites in Lang.) and > > IllegalStateException (29 possible call sites in Lang.) but I am not doing > > as far as implementing this, this could be done sooner or later. I really > > think that by covering these three cases, we would fall into the 80/20 > > rule. In addition, there is reason to cover other exceptions like JDBC's > > SQLException family of classes, but that's a job for Commons DbUtils or > > Commons DBCP, not Commons Lang. > > > > There is still the issue of the API itself (cf. some posts upwards), unless > your last comment implies that this is going to go in an "internal" package. > > Regards, > Gilles > > > Gary > > --------------------------------------------------------------------- > 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
