• Marcel (unregistered)

    brilliant.

    Long, complicated, useless code employed to generate a useless error message.

  • (cs) in reply to jack moxley
    jack moxley:
    Ive subdivided it into 3 parts so I can explain whats wrong.

    A: <snip> B: <snip> C: <snip> D: <snip>

    Count much?

  • ah (unregistered)

    I love the use of "hi" because that will lead to some great client bug reports.

    Bug report #3421: "Application fails when it attempts to greet the user"

  • (cs)

    I take EXCEPTION to that!

  • Aidan (unregistered) in reply to ammoQ
    ammoQ:
    The real WTF is obviously the use of the magic number 8. Should be a constant, i.e.

    static final int EIGHT=8; ... int i=EIGHT/0;

    Surely:

    static final int EIGHT = 8; static final int ZERO = EIGHT - EIGHT ; ... int i = EIGHT / ZERO ;

  • (cs) in reply to Aidan
    Aidan:
    ammoQ:
    The real WTF is obviously the use of the magic number 8. Should be a constant, i.e.

    static final int EIGHT=8; ... int i=EIGHT/0;

    Surely:

    static final int EIGHT = 8; static final int ZERO = EIGHT - EIGHT ; ... int i = EIGHT / ZERO ;

    Thanks for pointing that out. Anyway, an obvious improvement is still missing:

    static final int EIGHT = 8; static final int ZERO = EIGHT - EIGHT ; static final int CAUSE_EXCEPTION = EIGHT / ZERO ; ... int i = CAUSE_EXCEPTION ;

  • fanha (unregistered)

    Maybe my exception handling is rusty, but doesn't throwing in a catch block cause an immediate runtime termination? In this case, isn't the point of this to generate an exception that cannot be caught by other code? I could see doing this if some programmer was running a try-catch in the main loop and catching all exceptions without reporting them, and you wanted to crash it anyhow.

    Still a WTF, but the double throwing has a point.

  • (cs) in reply to swaj 
            String shortMsg = "short_msg_text1\n"
                        + "short_msg_text2";
        String detailMsg = "detail_msg_text1\n"
                         + "detail_msg_text2\n"
                         + "detail_msg_text3";

    Given that the variables are local, and aren't even used after being set, wouldn't javac be clever enough to optimize them out completely?

  • Shill (unregistered) in reply to fanha
    fanha:
    Maybe my exception handling is rusty, but doesn't throwing in a catch block cause an immediate runtime termination? In this case, isn't the point of this to generate an exception that cannot be caught by other code? I could see doing this if some programmer was running a try-catch in the main loop and catching all exceptions without reporting them, and you wanted to crash it anyhow.

    Still a WTF, but the double throwing has a point.

    No, you are wrong.

  • Siebe Tolsma (unregistered) in reply to ammoQ

    Of course, everyone knows that this code will need to be fixed come Y2K42, when computers learn how to deal with infinite numbers.

  • s. (unregistered) in reply to MurfWTF
    MurfWTF:
    Well, not entirely. The error messages aren't 'generated', the compiler would optimize those strings out to one static string, so no string concatenation would happen in that method, just assigning a variable from a static one.

    Pedantic I know, but there you go...

    Actually, the compiler would optimize tose strings out. Of the code. "Variable declared but never used" clause.

    captcha: vern. What is vern?

  • s. (unregistered) in reply to Aidan
    Aidan:
    Surely:

    static final int EIGHT = 8; static final int ZERO = EIGHT - EIGHT ; ... int i = EIGHT / ZERO ;

    Delicious -7.

  • sf (unregistered) in reply to Beau "Porpus" Wilkinson
    Beau "Porpus" Wilkinson:
    RK:
    Test code. Made it into the system. Sloppy process. Not a WTF.

    What the hell is it testing?

    Well, that that JVM won't allow a divide by zero of course. JVM's, you can never trust 'em.

  • l33t h4x0r (unregistered)

    I know what he's doing.

    ClientException() gets the values for shortMsg and detailMsg from the stack trace. It then gets the values of short_msg_text1,short_msg_text2, etc. from the object throwing the exception (it got this from the stack trace too) and then ClientException() shows a JOptionPane message box to the user.

    Now that's skill!

  • knock it off... (unregistered) in reply to MurfWTF
    MurfWTF:
    sobani:
    I know that, but if I read the code, I don't think: "Hey, java will ignore that unused String!"
    It's a good thing you don't think that, as it's wrong.
    sobani:
    but instead: "... and here we construct an error message from multiple strings"
    Sorry to be pedantic again, but it doesn't construct an error message from multiple strings. An error message is assigned from one static string. I think this matters because assigning a variable to a static value and letting it drop out of scope is pretty minor.

    Now please tell me where there is a "static String" here? (C anyone? ;o) You know that in OO "static" does have a special meaning. If you are being pedantic, don't mix up terminology like that. These Strings are local variables and therefore far from being "static". If they were, this would imply that they were "class variables", i.e. declared with the keyword 

    static
    somewhere in a class body.

    What you might have meant is that String literals in Java are "interned" (see java.lang.String#intern()), which means that they implicitely only exist once in memory (i.e. they are "singleton" String instances) to avoid redundancy.

    Thus

    "A" == "A"

    yields "true" (!) and is not the same as

    new String("A") == new String("A")

    (which yields "false"), instead it is equivalent to

    new String("A").intern() == new String("A").intern()

    which yields "true" again.

    Every time a literal is used in the code, it is implicitely "interned" by the compiler. This is also commonly known as the "flyweight" design pattern.

    MurfWTF:
    Unnecessary string concatenation is not (I've seen it bring servers down). The concatenation is done at compile time and the static String is constructed when the class is loaded. This method just assigns the value of a variable to a static string.

    Not so.

    Yes, static Strings in the OO sense are constructed when the class is loaded - but as we established above, there are no static Strings involved here...

    Concatenation itself is normaly not done at compile time, only for the special case of expressions which are compile time constants like "A"+"B" or "A"+5, which is in fact true for the WTF code.

    For all other cases, the following happens: This "+" operator does not really exist, as Strings are immutable in Java. It is instead replaced with a (mutable!) StringBuilder at compile time:

    int i = 5; 
String s = "A" + i;

    results in something like (exact bytecode might differ ;o)

    String s = new StringBuilder().append("A").append(i).toString();

    This is the reason why concatenation with "+" should never (!!!) be done inside a loop. Imagine the memory and gc (garbage collection) footprint if you put such a statement inside a loop with many iterations:

    String s;
for(int i=0; i<10000; i++)
   s = s + " ";

    This means 10000 StringBuilder instances created and copied over to 10000 String instances (by toString()) and all of this having to be garbage collected except the very last String instance!

    Instead, use a StringBuilder (or StringBuffer prior to Java5) explicitely:

    StringBuilder sb = new StringBuilder();
for(int i=0; i<10000; i++)
   sb.append(" ");
String s = sb.toString();

    Voila. One StringBuilder created, once copied over to the resulting String instance and then garbage collected.

    The speed differene here is around the factor 1000 or more (try it), and this is what brings servers down...

    If you are serious about being a (decent) Java developer and any of the above is new or surprising for you, go get a copy of "Effective Java" by Josh Bloch - and do it quickly!

  • (cs) in reply to TGV
    TGV:
    short_cmt_1
    short_cmt_reply_1
  • (cs) in reply to It's a Feature
    It's a Feature:
    If the application suddenly up and went "hi!" to me, then shut down, I'd definitely be wondering WTF!?

    I kinda want people to do this in real life. Run right up to you from nowhere and yell "HI!" and pass out. or even better, "HI!" stab Okay not in real life, but on television.

  • (cs) in reply to s.

    The first thing I thought when I read this snippet (after the "what?" "WHAT?" "WHAT?" phase was over) was "What the hell, that's like wrong in 8 different ways!"... worthless brownie points to whoever knows where that quote is from.

    Quick inspection can find 7 things that are wrong...

    1. Declaring strings for the error message that aren't returned.
    2. Using what looks like variable names in those error messages, but aren't, 'cause they're in quotes.
    3. Error message of "hi".
    4. "throws Exception"
    5. Throwing an exception and catching it immediately.
    6. That this is a method at all, when the caller could just use "throw new ClientException(0, "hi");" and save the effort.
    7. Explanatory comment that just repeats the name of the method.

    More worthless brownie points to anyone who can point out another (legit... no "no comments" or "magic numbers" stuff... funny though that is) thing wrong with the code, to make the quote valid.

    s.:
    Aidan:
    Surely:

    static final int EIGHT = 8; static final int ZERO = EIGHT - EIGHT ; ... int i = EIGHT / ZERO ;

    Delicious -7.

    "static final int" is not "#define"... you don't have to worry about extra parentheses or anything like that.

  • dkf (unregistered) in reply to s.
    s.:
    Aidan:
    static final int EIGHT = 8; static final int ZERO = EIGHT - EIGHT ; ... int i = EIGHT / ZERO ;
    Delicious -7.
    Alas, Aidan was not truly cognisant with the ways of the world and used 'static final int' instead of '#define' like he should have done for proper WTF effect. So your observation is erroneous. Nice try though.
  • David Schwartz (unregistered) in reply to ammoQ

    static final int EIGHT=8; ... int i=EIGHT/0;

    well, if you're going to make 8 a constant, why not do that for 0 also: static final int EIGHT=8; static final int ZERO=0; ... int i=EIGHT/ZERO;

    Actually, now that I think about it, this can be optimized:

    static final int EIGHT_OVER_ZERO=8/0; ... int i=EIGHT_OVER_ZERO;

    There you go. That's much better.

  • (cs)

    hi

  • (cs)

    OK, since we're being pedantic here I'll join. Yay!

    Martin:
    Perhaps this method only should throw an Exception as long as division by zero is not supported. Perhaps in some future JVMs this will be supported and the developer already thought of that. ...

    Actually, JVMs do support divide by zero, but not with integral types (byte, short, int, long). A JVM will happily let you divide by zero in floating point arithmetic. This is because IEEE 754 floating point has those nifty "NaN" (not a number) encodings. Note the plural - the IEEE standard stipulates any bit pattern where the exponent is all 1 and the fraction is not all 0 is interpreted as NaN.

    Anyhoo, this means that if the value of an floating point expression is not a number, this can be expressed in a floating point value. Hence the JVM can produce a sensible result for an expression such as

    8.0/0.0

    Go ahead, try it - the JVM wont blow up.

    However there is no way to encode anything but a number in a 2's-complement integer. Hence there is no sensible result that a JVM can produce for an expression such as

    8/0

    and it proceeds to throw an exception at you.

    Now, on the subject of garbage collection.

    knock it off...:
    This is the reason why concatenation with "+" should *never* (!!!) be done inside a loop. Imagine the memory and gc (garbage collection) footprint if you put such a statement inside a loop with many iterations:

    String s; for(int i=0; i<10000; i++) s = s + " ";

    This means 10000 StringBuilder instances created and copied over to 10000 String instances (by toString()) and all of this having to be garbage collected except the very last String instance!

    Actually, this isn't necessarily true. It depends on how intelligent the JVM's optimisations are. It certainly was the case that state-of-the-art garbage collection in virtual machines back in the 1990's almost always behaved the way suggested. However things have moved on a bit since then. In particular, these days good virtual machines (Java or otherwise) will do this wonderful thing called "escape analysis".

    In a nutshell, they would look how references to objects "escape" from blocks of code. The optimiser would look at what happens to the variable "s" after the loop. If the reference to the String doesn't escape from the enclosing block, then the optimiser will realise that the String object doesn't actually need to "exist" in the heap because nothing else could obtain a reference to it. If that is the case, then the String objects referred to by "s" can be allocated into the stack of the thread executing the code rather than the heap and discarded from the stack the moment they are no longer in use. This means that the garbage collector operating on the heap doesn't even see the String objects, and they don't incur any "garbage collection overhead" in the sense of the heap garbage collection needing to do work. Admittedly there still needs to be an CPU instruction or two for manipulating the stack, but that's all.

    However, all this is predicated on how the variable "s" is used after the loop and how intelligent the JVM is. So my point is that the code example above will not necessarily incur a nasty GC overhead. It may, however, and I certainly agree that in general using a StringBuilder as suggested would be better.

    In case you're wondering, I did my Ph.D. on garbage collection :).

  • (cs) in reply to sc0ticus
    sc0ticus:
    Would someone be so kind as to explain the WTF?

    To me, this looks like some test code that checks how the clientException is thrown. If the WTF is supposed to be the sloppy documentation or the throw then catch, then I don't think this is a very good one.

    Sure. How about the meaningless text assigned to the shortMsg and detailMsg variables that's never used? How about the throw new ClientException() with the really great message "hi"? How about the fact that this was left in a "base class Client object", which because it's a BASE CLASS was probably used as the ancestor of other classes? How about the fact that this appears to be from production code? Enough?

  • Me (unregistered) in reply to sobani

    First, we 'create' a NullPointerException The exception thrown then squashed is a DivideByZeroException, not a NullPointerException.

    CAPTCHA: gotcha- indeed I did.

  • (cs) in reply to Vechni
    Vechni:
    hi
    Don't Panic.
  • (cs) in reply to Beau "Porpus" Wilkinson
    Beau "Porpus" Wilkinson:
    RK:
    Test code. Made it into the system. Sloppy process. Not a WTF.

    What the hell is it testing?

    Maybe its just another attempt to finally find a computer to defy the laws of mathematics and divide by zero.

  • Please.. (unregistered) in reply to jack moxley

    Dear Jack,

    Please learn to form sentences in what appears to be your native language.

    Hint: There's a difference between "your" and "you are"..

    If a foreigner (like me) is able to learn English, so should you.

    • Bonus points for using "than" right..

    .. but damn you people make my eyes bleed.

  • (cs) in reply to nobody
    nobody:
    Arancaytar:
    I just love the "hi". But I've done things like this in testing - so all we can say here is that someone really should have read their code more carefully before going to production.

    throw new Exception("You suck.");

    Shouldn't it really say "Bye!"

    I don't know why you say goodbye; I say hello.

  • (cs) in reply to Doctor Algorythm
    Doctor Algorythm:
    In case you're wondering, I did my Ph.D. on garbage collection :).
    Don't they call it sanitation engineering now?
  • (cs) in reply to knock it off...
    knock it off...:
    Voila. One StringBuilder created, once copied over to the resulting String instance and then garbage collected.

    The speed differene here is around the factor 1000 or more (try it), and this is what brings servers down...

    If you are serious about being a (decent) Java developer and any of the above is new or surprising for you, go get a copy of "Effective Java" by Josh Bloch - and do it quickly!

    I'll be tentative here, because my point isn't to knock Java (even though I find the WorldOfJava personally unappealing).

    Is there a good reason to make a basic class such as "String" immutable? In what way does it differ from other basic classes such as "Integer" (at one end of the spectrum) or "Array" (at the other)?

    It seems to me that the binding of "String" to what in C++ terms would be "const char*" is an unfortunate case of premature optimisation. In 90+% of cases (particularly with strings) this is not what you want. Forcing yer average dimwit programmer to understand the complexities of StringBuilder after the event does not sound like a productive way to encourage sensible coding practice. Yes, I know it's the Flyweight pattern (which I've never seen in production code outside of the languages which follow the "immutable string" idiom), but so what?

    Why, exactly, should

    "A" == "A"

    produce a different result from

    new String("A") == new String("A")?

    Frankly, it looks like a failed nod to functional programming to me.

    If you want functional programming on the JVM (or for that matter on .NET), I'd suggest Scala instead. So far, I haven't come across any WTF moments with Scala, as opposed to the head-scratching (not even WTF, but, "Huh?") that I get with Java.

    Fine language, BTW. Keep on building those strings.

  • (cs) in reply to real_aardvark
    real_aardvark:
    Is there a good reason to make a basic class such as "String" immutable? In what way does it differ from other basic classes such as "Integer" (at one end of the spectrum) or "Array" (at the other)?
    Immutable objects mean aliasing doesn't matter... you can do
    String a = "Hi!";
String b = a;
someMethod(b);
    with impunity, and a will always still be "Hi!"... you don't have to worry about it changing. Incidentally, all of the primitive wrapper classes, Integer, Boolean, etc... are all immutable too... so your answer for "How does String differ from Integer" is "it doesn't". It differs from Array in that if you do
    int[] a = new int[]{1,2,3,4,5};
someMethod(a);
    then you can't guarantee what a will contain after the method returns... the method could change the array's entries. This can, of course, be a good thing... it depends on the situation.

    There is even a method, String.intern(), which collapses matching strings into the same object - if you have large numbers of String objects, and you run a = a.intern() on every single one, then any Strings that happened to match will all become references to the same String object. Since the Strings are immutable, this will have exactly zero effect on the rest of the program, but will let the garbage collector get rid of some of those extra String objects.

    Of course, it's a tradeoff of memory use for CPU time, but so many things are.

    real_aardvark:
    Why, exactly, should 
    "A" == "A"
    produce a different result from 
    new String("A") == new String("A")?
    Frankly, it looks like a failed nod to functional programming to me.
    The compiler will see that "A" and "A" are the same string, and will save some space in the .class file and in memory, and only create one String object to store both of them. It's even automatically added to the String.intern table. Having "A" != "A" would just mean space being pointlessly wasted, for no gain (well, maybe the compiler itself would be slightly simpler, and it'd be slightly easier for Java teachers to demonstrate the "== on Strings doesn't do what you think" thing in class... but no real benefit to the compiled program).

    However, when you use new String("A") you're specifically saying you want a new String object, you don't want to reuse an existing one.

  • (cs) in reply to RK
    RK:
    Test code. Made it into the system. Sloppy process. Not a WTF.

    I hope you are being sarcastic...

    First, 99% of the WTFs in existence come from code initially written to test something or as a proof of concept but then made it in the production system.

    Second, WTF were they trying to test? That the JVM's exception handling system was working?

  • (cs) in reply to real_aardvark
    real_aardvark:
    knock it off...:
    Voila. One StringBuilder created, once copied over to the resulting String instance and then garbage collected.

    The speed differene here is around the factor 1000 or more (try it), and this is what brings servers down...

    If you are serious about being a (decent) Java developer and any of the above is new or surprising for you, go get a copy of "Effective Java" by Josh Bloch - and do it quickly!

    I'll be tentative here, because my point isn't to knock Java (even though I find the WorldOfJava personally unappealing).

    Is there a good reason to make a basic class such as "String" immutable? In what way does it differ from other basic classes such as "Integer" (at one end of the spectrum) or "Array" (at the other)?

    Uh, Integer is also immutable. There are huge advantages to immutable classes, I would suggest reading the Bloch book suggested in the post you are responding to.

    It seems to me that the binding of "String" to what in C++ terms would be "const char*"...

    Actually its more analogous to the stl string class.

    Forcing yer average dimwit programmer to understand the complexities of StringBuilder after the event does not sound like a productive way to encourage sensible coding practice. Yes, I know it's the Flyweight pattern (which I've never seen in production code outside of the languages which follow the "immutable string" idiom), but so what?

    Whats so complex about StringBuilder.append()? If you can't understand that class, I don't want you anywhere near any code I may ever use.

    Why, exactly, should 
    "A" == "A"
    produce a different result from 
    new String("A") == new String("A")?

    Why should 

    1 + 1
    produce a different result from 
    2 + 2
    ? Different lines of code are not guaranteed to return the same thing. Yes, many people think one of those lines should do something different, but usually they are complaining about the second line checking if the references are equal instead of the objects.

  • emjoi (unregistered) in reply to Ian

    You can set a breakpoint in that exception and have a look at the state of things.

    It may be that for this particular code, the contents of the text is unimportant.

  • Big pants magee (unregistered)

    If you need to change the 8/0 to a 7/0 you would have to go through a whole build phase to make the change. The method should clearly be driven by an XML configuration file.

  • dubya (unregistered) in reply to Beau "Porpus" Wilkinson
    Beau "Porpus" Wilkinson:
    RK:
    Test code. Made it into the system. Sloppy process. Not a WTF.

    What the hell is it testing?

    What the hell is testing?

  • (cs)

    Actually this is a perfectly valid boundary case testing function. I imagine it was left in after development.

  • (cs)

    From a program I am writing:

    bool Client::handle(Message* msg) { sptr<Message> smsg; int oid, magic; string clas;

    if (msg == NULL) {
cerr << "YOW! KELLY CLARKSON!!!" << endl;
return true;
}
switch (msg->type) {
  • Pt (unregistered) in reply to jspenguin
    jspenguin:
    From a program I am writing:

    bool Client::handle(Message* msg) { sptr<Message> smsg; int oid, magic; string clas;

    if (msg == NULL) {
cerr << "YOW! KELLY CLARKSON!!!" << endl;
return true;
}
switch (msg->type) {

    And that's why you shouldn't get payed

    CAPTCHA: craaazy, exactly.

  • kl (unregistered)

    This code checks if its running Java! Because if it wasn't, there would be no support for exceptions and 8/0 wouln't throw, so code couldn't throw ClientException as well.

    This is just robust programming that's ultimately portable and even takes parallel universes into account!

  • xerez (unregistered)

    Since when is WTF all about trying to figure out what the code actually does? I thought it was about laughing at, not being, stupid programmers.

  • (cs) in reply to ammoQ
    ammoQ:
    static final int EIGHT = 8; static final int ZERO = EIGHT - EIGHT ; static final int CAUSE_EXCEPTION = EIGHT / ZERO ; ... int i = CAUSE_EXCEPTION ;

    Indeed, a major improvement. That will bring the app to its knees so much more efficiently.

    What even happens to a "static final" initializer when its rvalue throws an exception?

  • deworde (unregistered) in reply to Doctor Algorythm

    I think this is why this code was written, so that I could find out this useful piece of information.

  • deworde (unregistered) in reply to real_aardvark
    Bob:
    If you want functional programming on the JVM (or for that matter on .NET), I'd suggest Scala instead. So far, I haven't come across any WTF moments with Scala, as opposed to the head-scratching (not even WTF, but, "Huh?") that I get with Java.

    Standard Law of WTF's: The number of WTF's is directly proportional to the number of users*the lcc(language complexity constant).

    How many people use Scala?

Leave a comment on “An Interesting Way of Excepting”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article