Dumb java code award

[Daniel Dyer]

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.

 

[cis148]

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?

 

[Michael Willer]

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:

 

[cis148]

I agree. Hilarious!

 

[Alex Hunsley]

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.

 

[Mike Schilling]

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?

 

[James McGill]

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.

 

[Mike Schilling]

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

 

[vovanduc]

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

 

[Chris Uppal]

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

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

 

[Oliver Wong]

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

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Oliver Wong schreef:

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. =(

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFENOlke+7xMGD3itQRAhoLAJ9urIul+tZofUNL10VGYv7tdh8mNACfaQXi
0i3+ZhTfwYoK73i8Ak1OvBM=
=cS2K
-----END PGP SIGNATURE-----

 

[Oliver Wong]

Oliver Wong schreef:

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?.

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