>>>>> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes:
Mark> I find the example a bit contrived. You will get a crash anyway in f2() Mark> since you trashed env and are using it. Yes... let's not talk about asserts in the abstract. I don't think that sheds much light. >> > assert((*env)->GetArrayLength(env, receivedFromAddress) > 4); Mark> The asserts failed because they were testing the wrong condition (they Mark> test for > instead of ==). Oops. Mark> This code is so tightly bound to the private Mark> VM method that I don't feel argument assert checking buys us anything. If the code in question lives in a different file, then I think that having the assert does add something -- it ensures that a change in one place has a chance of being caught in the other. This can be very useful. In this case, fixing the assertion to be correct certainly wouldn't hurt anything, and would provide some mild protection against changes. Another question to ask is whether an assert is the appropriate self-checking mechanism at a given point. If it is purely classpath-internal stuff, then this is probably ok. That is especially true if our test suite actually runs this code path -- that way we can be reasonably sure that a Classpath release won't trigger the assertion. In some other situations a Java exception is probably more appropriate. Tom _______________________________________________ Classpath-patches mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath-patches
