Re: Ensuring a method is overridden
Robert Klemme wrote:
On 9 Sep., 11:45, Christian <fakem...@xyz.de> wrote:
Robert Klemme schrieb:> On 09.09.2009 05:01, Roedy Green wrote:
On Tue, 08 Sep 2009 22:42:31 +0200, Robert Klemme
<shortcut...@googlemail.com> wrote, quoted or indirectly quoted
someone who said :
Also, asserts are (and should be) OFF most of the time.
An assert on program structure needs to be on only once.
I am not so sure about turning asserts off. Why?
1. a clever compiler optimises them out or makes them low overhead.
They cannot be optimized away by the compiler because enabling and
disabling them is a function of the JVM - not a compile time option.
the JVM is the compiler ... its java runtime is compiletime
Roedy did not mention JIT. When I read "compiler" without further
qualification in a Java forum this translates to "Java compiler".
Strictly speaking JIT is purely optional while you always need a Java
compiler to get bytecode from your sources.
Anyway, that whole discussion is meaningless with regard to Roedy's
statement that you want assertions on all the time. This is abusing
assertions and not making best use of them.
Assertions are another way of catching bugs in production. If your
assertions are causing a large performance penalty, then you can
consider disabling them in production, or adjusting them to make more
sense. Otherwise, leaving them in and on is considered a best practice.
You don't need to test for all invariants everywhere, especially
invariants that would cause an exception anyway (such as a collection
must only contain objects of a certain class. That will be caught by a
ClassCastException, which is a built-in assertion you can not disable)
In other words, assertions should be used where failure of the invariant
may change the output of the program in subtle ways, not where failure
will itself cause an exception.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>