The main reason not to use assertions is that they can be disabled at runtime, rendering them fairly useless IMO.
I think this was a fundamental goal of assertions. I imagine that the idea is to enable assertions during heavy development time, and disable them once the code reaches a certain degree of stability.
The enable/disable concept is appealing to some for performance reasons. I think Sun claims that an assertion will have no performance cost if they are disabled. I'm not sure how much of a difference it would make.
Personally, I would remove the null parameter checking entirely and let> the code throw a NPE. The caller will see their offending method in the stack trace.
I share your philosophy on this. In my opinion, the redundant parameter checking everywhere (especially for null) does more harm than good.
I like assertions, except in cases of input checking for a client external to the application (like a web service client, for example).
I don't see the enable/disable as much of an issue. The RuntimeException cases are supposed to be caught during development anyway.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
