commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gillese...@gmail.com>
Subject Re: [lang] org.apache.commons.text.lookup.IllegalArgumentExceptions to [lang].
Date Thu, 05 Sep 2019 08:33:39 GMT
Le jeu. 5 sept. 2019 à 02:50, Gary Gregory <garydgregory@gmail.com> a écrit :
>
> On Wed, Sep 4, 2019 at 4:51 PM Xeno Amess <xenoamess@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message