=?windows-1252?Q?Re=3A_compare_several_boolean_matrix's?=
Arne Vajh=F8j wrote:
Lew wrote:
Arne Vajh=F8j wrote:
I would have done a few things differently, but ...
public class MatrixSummarize {
public static boolean[][] summarize(boolean[][][] matrices) {
assert matrices.length % 2 == 1 : "Number of matrices must be odd=
";
Nitpicks: Some details that separate pedagogy from production.
Arne's code is very good, and proper for instruction. However, if it wer=
e
to serve in production there is more to do.
This is an improper use of 'assert' because there is no code to
enforce the invariant. Properly, there should be argument-checking prior=
to
the assertion so that it represents an actual invariant.
There's no check for a null argument. One could assert non-nullity after
the check.
By dropping the 'assert' in here like this, Arne has presented a secret
challenge to fill in the gaps, as anyone schooled in the use of 'assert'
might have noticed.
I am not that advanced.
Passing null, passing arrays with wrong dimensions etc. will all
give various exceptions.
The odd number requirement will not give an exception if violated.
So I flipped a coin (virtually) between an if throw new
RuntimeException and the assert. Assert won.
It's not a coin flip. They aren't equivalent. This is well known in Java,=
as 'assert' has been around since Java 1.4.
Assertions are more runtime comments than code. They do you no good when
disabled. Exceptions cannot be suppressed.
Assertions are not even slightly meant for argument checking of public
methods.
That's the job of exceptions.
Assertions come in after the exception, or in private methods, to document=
and enforce invariants for programmers. For example, a getter method that=
expects the private member to be non-null can assert non-nullity. Only
something under complete control of the implementation, i.e., the private=
member, is involved, so it's time for 'assert'.
When it's a public method you don't have that control. So you start with
a runtime check. Once that check is complete, i.e., either the method has r=
eturned, thrown an exception, or continued to where supposedly you've just=
guaranteed non-nullity, if you are still in the method it is safe to
assert non-nullity.
public void checkArgumentsThenAssert(Foo foo, Bar bar)
{
/* It doesn't make sense to assert non-nullity here because you
* simply do not have that guarantee.
*/
if (foo == null || bar == null)
{
throw new IllegalArgumentException("Null argument");
}
/* NOW you have the guarantee. It would take a code mistake to mess up. =
*/
assert foo != null && bar != null : "There was a code mistake";
}
A quick Google will reveal the expert wisdom on the subject.
http://lmgtfy.com/?q=java+assert
http://docs.oracle.com/javase/1.4.2/docs/guide/lang/assert.html
"There are also a few situations where you should not use them:
"Do not use assertions for argument checking in public methods."
....
"Do not use assertions to do any work that your application requires for
correct operation."
--
Lew