On Thu, 25 Jul 2024 at 17:46, Gary Gregory <garydgreg...@gmail.com> wrote: > > Java assertions only make sense in specific cases. > > Never in test code, use JUnit for that (or TestNG). > > It might make sense in low level libraries to enable some semantic checking > which can be enabled on the CLI. This might be more convenient instead of > "if debug is on AND some condition then throw a runtime exception". > > The above would be orthogonal to using a logging framework. > > In general though, I don't use Java's assert keyword.
What about the following? https://github.com/apache/commons-io/blob/c155293776f49eef93547aca9cf181c8a0591cad/src/main/java/org/apache/commons/io/input/ReadAheadInputStream.java#L488 https://github.com/apache/commons-io/blob/c155293776f49eef93547aca9cf181c8a0591cad/src/main/java/org/apache/commons/io/input/ReadAheadInputStream.java#L498 https://github.com/apache/commons-io/blob/c155293776f49eef93547aca9cf181c8a0591cad/src/main/java/org/apache/commons/io/input/ThrottledInputStream.java#L130 https://github.com/apache/commons-io/blob/c155293776f49eef93547aca9cf181c8a0591cad/src/main/java/org/apache/commons/io/input/ThrottledInputStream.java#L150 > Gary > > On Thu, Jul 25, 2024, 12:24 PM sebb <seb...@gmail.com> wrote: > > > I'm not convinced that it ever makes sense to use assert checks in our > > code. > > > > In the case of test code, it seems to me that a JUnit assertion makes > > more sense, as it is unconditionally checked. > > > > In main code, does it make sense to use a check that is not guaranteed to > > run? > > I would expect to see an IllegalStateException instead if the check fails. > > > > However, if an assert IS needed, in most cases it needs a message to > > ensure any failures contain sufficient information to determine the > > cause of the failure. > > > > For example: > > > > assert length >= 10; // bad: what is the value of length? > > > > assert length >= 10 : "Length: " + length; // good: show unexpected value > > > > assert isEmpty; // does not need a message > > > > Sebb > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
