Dumb java code award

Thread view:

cis148@yahoo.com - 04 Apr 2006 21:16 GMT

We've seen our share of some real gems, but today, a coworker and I
found a clear winner:

numInvalidRecs = numInvalidRecs++;

Can you top it?

Reply to this Message

Daniel Dyer - 04 Apr 2006 20:20 GMT

> We've seen our share of some real gems, but today, a coworker and I
> found a clear winner:
>
> numInvalidRecs = numInvalidRecs++;
>
> Can you top it?

Yes. But rather than post some of my less lucid moments, I'll point you
to the Daily WTF (http://www.thedailywtf.com), which is full of this kind
of thing, only much worse.

Dan.

Signature

Daniel Dyer
http://www.dandyer.co.uk

Reply to this Message

Michael Willer - 04 Apr 2006 21:46 GMT

Dan, that's a great link.

All, how about giving Dan an award for that? Just the front example had
me rolling on floor, howling with laughter. :-)

thanks Dan.

Daniel Dyer skrev:

>> We've seen our share of some real gems, but today, a coworker and I
>> found a clear winner:
[quoted text clipped - 11 lines]
> --Daniel Dyer
> http://www.dandyer.co.uk

Reply to this Message

cis148@yahoo.com - 04 Apr 2006 21:56 GMT

I agree. Hilarious!

Reply to this Message

Alex Hunsley - 04 Apr 2006 23:58 GMT

> We've seen our share of some real gems, but today, a coworker and I
> found a clear winner:
>
> numInvalidRecs = numInvalidRecs++;
>
> Can you top it?

Excellent!

OT aside: I like the fact that Python does away with all that ++ and --
nastiness. Less chance of writing obfuscated nonsense, and you can still
use += style operations like x += 1.

Reply to this Message

Mike Schilling - 05 Apr 2006 01:15 GMT

> We've seen our share of some real gems, but today, a coworker and I
> found a clear winner:
>
> numInvalidRecs = numInvalidRecs++;
>
> Can you top it?

It would be worse still in C or C++, since there it would give undefined
behavior. But that's just frosting on the cake.

Let's see, testing my Java skills -- it's effectively a no-op, isn't it?

Reply to this Message

James McGill - 05 Apr 2006 01:32 GMT

> Let's see, testing my Java skills -- it's effectively a no-op, isn't
> it?

Yes, no side effect on the variable from the post increment which is
thrown away because the assignment is already done.

Reply to this Message

Mike Schilling - 05 Apr 2006 04:34 GMT

>> Let's see, testing my Java skills -- it's effectively a no-op, isn't
>> it?
> Yes, no side effect on the variable from the post increment which is
> thrown away because the assignment is already done.

I parse it a bit differently, though arriving at the same result

i = i++;

1. The value of i is saved
2. i is incremented
3. the saved value of i is copied to i

That is, i is changed but then changed back. Hmm, I suppose if i were
visible to multiple threads (say, if it's a field rather than a local
variable) it's conceivable that some other thread could see the changed
value of i. So it's not quite a no-op, it's something worse :-)

Reply to this Message

vovanduc@gmail.com - 05 Apr 2006 05:00 GMT

with your code i=i++ step 3 never happens -> so .. :)

Reply to this Message

Chris Uppal - 05 Apr 2006 11:47 GMT

> i = i++;
>
[quoted text clipped - 6 lines]
> variable) it's conceivable that some other thread could see the changed
> value of i. So it's not quite a no-op, it's something worse :-)

Ideally there would be several threads potentially executing the same code, in
which case the value of i would normally stay constant, but every once in a
blue moon might jump up by a bit ;-)

-- chris

Reply to this Message

Oliver Wong - 05 Apr 2006 21:06 GMT

> We've seen our share of some real gems, but today, a coworker and I
> found a clear winner:
>
> numInvalidRecs = numInvalidRecs++;

I wrote a function which tests whether a reference to Frame is null or
not:

<code>
public boolean isNull(Frame reference) {
try {
new Window(reference);
} catch (IllegalArgumentException e) {
return true;
}
return false;
}
</code>

I submitted it as a regression bug to Sun because this works in 1.5, but
no longer works in 1.6 (in 1.6, the constructor for Window no longer throws
IAE when the passed-in parameter is null). They closed it with "not a bug"
though. =(

- Oliver

Reply to this Message

Hendrik Maryns - 06 Apr 2006 11:11 GMT

Oliver Wong schreef:

>> We've seen our share of some real gems, but today, a coworker and I
>> found a clear winner:
[quoted text clipped - 19 lines]
> throws IAE when the passed-in parameter is null). They closed it with
> "not a bug" though. =(

If I remember right from my OO classes, declaring an exception can be
thrown *never* implies it *must* be thrown in specific cases, except
explicitly stated. So this indeed is ?not a bug?.

H.
- --
Hendrik Maryns

==================
www.lieverleven.be
http://aouw.org

Reply to this Message

Oliver Wong - 06 Apr 2006 15:58 GMT

> Oliver Wong schreef:
>>> We've seen our share of some real gems, but today, a coworker and I
[quoted text clipped - 24 lines]
> thrown *never* implies it *must* be thrown in specific cases, except
> explicitly stated. So this indeed is ?not a bug?.

The exact wording of the 1.5 Javadocs is:

<quote>
Throws:
IllegalArgumentException - if the owner's GraphicsConfiguration is not
from a screen device
IllegalArgumentException - if owner is null. This exception is always
thrown when GraphicsEnvironment.isHeadless() returns true.
</quote>

To me, "Throws" means "I guarantee I will throw it under these
conditions, or else I am not fufilling my contract". If they instead meant
"I may or may not throw", I would have expected wording similar to what is
seen, for example, in the docs for the LinkedList class:

<quote>
The iterators returned by the this class's iterator and listIterator methods
are fail-fast: if the list is structurally modified at any time after the
iterator is created, in any way except through the Iterator's own remove or
add methods, the iterator will throw a ConcurrentModificationException.
Thus, in the face of concurrent modification, the iterator fails quickly and
cleanly, rather than risking arbitrary, non-deterministic behavior at an
undetermined time in the future.

Note that the fail-fast behavior of an iterator cannot be guaranteed as it
is, generally speaking, impossible to make any hard guarantees in the
presence of unsynchronized concurrent modification. Fail-fast iterators
throw ConcurrentModificationException on a best-effort basis. Therefore, it
would be wrong to write a program that depended on this exception for its
correctness: the fail-fast behavior of iterators should be used only to
detect bugs.
</quote>

- Oliver

Reply to this Message

Dumb java code award

Free Magazines