Re: Ensuring a method is overridden
On 09.09.2009 18:40, Daniel Pitts wrote:
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.
Well, by you apparently. I would not claim this is a general best
practice in the Java world. If I consider checks that important that I
don't want to switch them off, then I wouldn't place them after an
"assert" - I'd just do them all the time.
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)
Sometimes it is crucial to determine the point in time when an error
occurs in order to help in debugging. Your ClassCastException (not
assertion!) might show up at a point where it is not clear any more when
that illegal object made it into the collection. If a class is complex
then it can be reasonable to include an invariant check via assert in
every method that changes state (or even in _every_ method in certain
cases, e.g. when state of referenced objects can be changed outside the
class).
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/