On Thu, Sep 5, 2019 at 4:33 AM 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. > The intent is not for an internal package, but for a public API, which you can see from the PR since it is in the existing 'exception' package, as opposed to a new 'internal' package. You will also see that the new class is used from all over Commons Lang, therefore making it impossible to use a package private class. While there may be room for a lambda styled (not reflection) implementation, the call sites would be uglier and harder to maintain. I would be OK with adding ExceptionUtils with lambdas with the ExceptionClass::new style but this is separate IMO. The call site should pick which API it wants. Gary > > Regards, > Gilles > > > Gary > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
