Is Groovy's assert a good idea for production code, unlike Java's assert?

Question

In Java it's known that using the assert keyword is usually a bad idea, as its behavior is dependant on the runtime enviornment (it doesn't do anything by default, unless the -enableassertion is passed to the java runtime).

Is Groovy's assert different? Is it always executed in production code, and is it recommended to use in production code? (In Java you would use something like Preconditions instead)

From my sanity tests it seems that by default assert works well without any flags, and that it's actually way more powerful than the Java keyword (see Power Assert) - I'm just looking for an official/complete answer, as opposed to my anecdotal one.

Wing

https://mcmap.net/q/663944/-assertions-in-groovy/… – Yaya

@Yaya - well, my question is "sort of a duplicate", but I think it's more well formulated ... perhaps the other question should be closed as a dup now? – Wing

Sorry, I was saying it was related, not a dupe ;-) Peter Niederwieser makes a couple of good points that aren't necessarily already covered by the answer here... – Yaya

@Yaya - well, it seems to be highly related even if not "exact dups" ... I'm not sure there's value in having both questions open ... but I won't nitpick about it. Thanks for the reference anyway! – Wing

I would not consider this as dupe – Seer

"In Java it's known that using the assert keyword is usually a bad idea". WRONG! It is known that using assert is always a GOOD IDEA. It is a bad idea ONLY WHEN IT IS BEING USED INCORRECTLY (i.e. when removing the assert would change the program's meaning). And one should always leave "-enableassertions" on UNLESS the asserts produce a large performance hit. After all, what good is a program in which an assertion fails in the first place. "Patient is dead because the algorithm went haywire, but at least the program ran to completion"? NOPE! – Predestinarian

Answer 1

Groovy assert is always executed in production code, and I recommended to use in production. I see the following as being roughly equivalent, but the Groovy version is more compact

Groovy

assert file.exists(), "$file does not exist"

Java

if (!file.exists()) {
    throw new SomeRuntimeException(file + " does not exist");
}

Intumesce

Groovy, that's what I thought (pun intended). I'm loving Groovy more and more as I use it. – Wing

You should be mindful of the fact that AssertionError is a java.lang.Error, and won't be caught by catch(e), you should use catch(Throwable e) – Lucrative

@loteq IMO you should rarely (if ever) catch the Throwable thrown by an assertion, because usually a failing assertion is not recoverable – Squally

Then to go back to the original question, I don't think that assert should be used. Not every error is recoverable, but every error needs to be caught and handled at some level in a production system. Finding asserttion errors in the log files is a no-no for me, if I'm not notified that something fundamental has gone wrong. – Lucrative

Using the assert like this in Groovy is appropriate only in half-arsed coding!! A failed assert means that the developer's assumptions are being violated (as in: 'assert x > 0 : "If $x <= 0, there is a problem with the algorithm"' or 'assert x instanceof Double : "If this is anything else than a Double, upcoming code won't be reliable"'). Checking that a file exists should yield a simple java.io.FileNotFoundException or similar, so that the caller can handle the problem. – Predestinarian

You should not catch Throwable, but catching AssertionError would be quite acceptable if you can recover from that. – Ayesha