org.apache.geode.internal.Assert was introduced as a temporary stand-in for Java assertions when GemFire was built using a version of JDK that was pre-assertions. I think we probably should plan to delete it whether we use assertions or not.
On Thu, Jul 19, 2018 at 1:07 PM, Udo Kohlmeyer <u...@apache.org> wrote: > +1 to what Anthony said. If you need to assert that you have received the > data or even that it is in the correct format, you are missing to > validations and service/method contract. > > Assert, be it Java or JUnit, should really be for testing only. The > code/methods/functions/services should protect themselves from malicious > inputs. > > --Udo > > > > On 7/19/18 08:15, Anthony Baker wrote: > >> I’m not a fan of assertions in product code. Usually it’s a sign of >> missing error handling. Crashing a geode server when an unexpected >> condition is encountered is usually not the right thing. >> >> Anthony >> >> >> On Jul 18, 2018, at 8:18 PM, Jacob Barrett <jbarr...@pivotal.io> wrote: >>> >>> There is a HUGE difference between Java language assert and an class >>> called Assert. >>> >>> Java language asserts are disabled at runtime by default. They should >>> only be used for testing assertions when running in a “Test” mode. Since >>> under such conditions you should have good unit test doing the same it >>> seems redundant to even have them in the code. >>> >>> Under what conditions are you seeing both types of assertions being used >>> in the main code? >>> >>> On Jul 18, 2018, at 6:52 PM, Galen O'Sullivan <gosulli...@pivotal.io> >>>> wrote: >>>> >>>> Hi all, >>>> >>>> I'm wondering what the collective's opinion of assertions is. I notice >>>> there's an org.apache.geode.internal.Assert class, which is used some >>>> places, and that plain old Java assertions are used in other places. >>>> Can we >>>> remove one of these and use the other? Should we be including >>>> assertions in >>>> new or refactored code? >>>> >>>> Thanks, >>>> Galen >>>> >>> >
