While powerful, the problem with Java assertions is that they must be
explicitly enabled (e.g. with the JVM switch, -ea), as Jake already pointed
out, which makes them dangerous to rely on.
Additionally, in general, there is nothing about Assertions that require
they only be used for testing purposes. In fact, many good frameworks,
e.g. Spring, use assertions to validate input passed by the caller to a
method invocation in order to ensure the arguments adhere to the method
contract. Any well-written/implemented API validates its input. This is
indeed the intent and purpose behind the org.springframework.core.Assert
class [1] provided by the core Spring Framework, and is used extensively
throughout all Spring "production" code.
Would your rather see this...
[<return-type>|void] someMethod(String input) {
if (input != null && !input.isEmpty()) {
throw new IllegalArgumentException(String.format("Input is
required; input was [%s]", input));
}
// potentially other "conditional statements" for input validation
...
}
Or this...
[<return-type>|void] someMethod(String input) {
assertThat(input).describeAs("Input is required; input was [%s]", input
).isNotEmpty();
// additional assertions as needed
...
}
It is equally important to note that using Assertions, in no way, implies
that a system comes to a grinding halt and falls over. That is absurd. It
merely implies that the system "fails-fast" and gives the user an
appropriate response, which is typically implemented using Java's familiar
*Exception* mechanics to bubble out a RuntimeException with appropriate
information about the context and condition in which the error occurred
along with an appropriate handler at the API layer to: include a
corrective-action and/or log a message, trigger an alert, etc, etc.
Having stated the above, I think *AssertJ* is the best, most intuitive
framework (IMO) available for implementing assertions whether in tests or
production code.
$0.02
-j
[1]
https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/util/Assert.html
On Thu, Jul 19, 2018 at 1:51 PM, Kirk Lund <kl...@apache.org> wrote:
> 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
> >>>>
> >>>
> >
>
--
-John
john.blum10101 (skype)
