20

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.

ripper234
  • 222,824
  • 274
  • 634
  • 905
  • http://stackoverflow.com/questions/5203680/assertions-in-groovy/5211791#5211791 – tim_yates Nov 10 '11 at 10:36
  • @tim_yates - 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? – ripper234 Nov 10 '11 at 10:57
  • 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... – tim_yates Nov 10 '11 at 11:02
  • @tim_yates - 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! – ripper234 Nov 10 '11 at 11:19
  • I would not consider this as dupe – Jonny Heggheim Nov 10 '11 at 18:03
  • "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! – David Tonhofer Nov 27 '13 at 12:19

1 Answers1

22

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");
}
Dónal
  • 185,044
  • 174
  • 569
  • 824
  • 3
    Groovy, that's what I thought (pun intended). I'm loving Groovy more and more as I use it. – ripper234 Nov 10 '11 at 10:11
  • 3
    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) – Luis Muñiz Aug 07 '13 at 16:10
  • 2
    @loteq IMO you should rarely (if ever) catch the `Throwable` thrown by an assertion, because usually a failing assertion is not recoverable – Dónal Aug 08 '13 at 08:13
  • 1
    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. – Luis Muñiz Aug 09 '13 at 14:09
  • 9
    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. – David Tonhofer Nov 27 '13 at 12:16
  • 4
    You should not catch `Throwable`, but catching `AssertionError` would be quite acceptable if you can recover from that. – Renato Jul 28 '14 at 20:02