• (unregistered)

    Wow. The real WTF here is the fact that CC numbers of all things are being handled this way. In the interests of security we should be know the company this comes from... I'd hate to think my CC numbers could end up there..

  • (cs)

    I guess this programmer subscribes to the old adage - "If at first you don't succeed, try, try again."

  • (unregistered)

    Does the fact that it's inside the catch prevent it from being tail recursion, and therefore make it so the compiler can't turn the recursion into a loop? Any decent compiler should compile this into non-recursive code otherwise.

  • (unregistered)

    WTF is it, oh is java.

  • (cs)

    Thats a bit spooky, to be honest. Credit card details should be the last thing to be handled this recklesly.

  • (unregistered)

    Hey... I'm the one that submitted this.

    I just wanted to share my speculations about how this code originated.  The code basically does a busy-wait on a file that is dropped into the filesystem.  If the busy-wait caused an exception (due to maybe a disconnected NFS or SMB filesystem???) it would cause this programmer's lovely busy-wait to fail.

    My guess would be that they put the nasty busy-wait code into production, it failed with an uncaught exception, and then they "fixed" it.

  • (unregistered)

    [:'(] Wow, oh wow!!!  This code pains me.  This must be from a late night code spree or something, the author must have... Nevermind, this is definately a WTF. [B]

  • (cs) in reply to

    That's crap code...really crap code.

  • (cs)

    That's a very good demonstration of how not to use try..catch blocks.

  • (unregistered) in reply to Jacob K

    Leave it to a java programmer to make a VB programmer look smart...

  • (unregistered) in reply to

    What's scarier to me is the way the two programs communicate to each other.  Dropping files into directories and then polling for files.  This is just plain wrong and should not be in ANY production system.  I know that unfortunately far too many systems operate this way and far too many systems probably have worse code then this.  Still any programmer or IT staff member that "architects" this kind of "solution" should be shot and pissed upon.



  • (cs) in reply to
    :
    What's scarier to me is the way the two programs communicate to each other.  Dropping files into directories and then polling for files.  This is just plain wrong and should not be in ANY production system.  I know that unfortunately far too many systems operate this way and far too many systems probably have worse code then this.  Still any programmer or IT staff member that "architects" this kind of "solution" should be shot and pissed upon.


    I seem to recall some old antiquated credit card verification systems dumping files that had to be read by an application that would wait for it. I think we dumped the software as soon as we could and worked with a package that integrated into PERL [+o(] and allowed it to call a function directly, rather than drop files off.
  • (unregistered)

    I don't see the WTF here. The programmer just needed a way to detect if a file had been dropped in the filesystem, and if not, just recurse and wait again.

    Sure it's not the best way he could have done it, and a daemon would have worked better, but this is probably the simplest and easiest way he could do it, and he probably had more important things to attend to.  

  • (unregistered)

    I hope this is not code behind a website...  I'm sure if they throw CC numbers around randomly like that... they probably won't be doing any encryption or using SSL... 

    WTF indeed...  (remind me to stop buying things using my CC online... there are way too many crap programmers out there!)

  • (cs) in reply to
    :
    I don't see the WTF here. The programmer just needed a way to detect if a file had been dropped in the filesystem, and if not, just recurse and wait again.

    Sure it's not the best way he could have done it, and a daemon would have worked better, but this is probably the simplest and easiest way he could do it, and he probably had more important things to attend to.  



    [:O] You have GOT to be kidding! What about:

    while (!file_there) {
       Thread.Sleep(1000);
       file_there = checkFile();
    }

    That's just one out of a million *easy* ways to handle that problem. Exceptions are meant to be used when something out of the ordinary happens, not as means of regular contol!
  • (cs)

    I wonder where they put this 2 lines:

    [code language="c#"]
    PrintStream out = new PrintStream(new BufferedOutputStream(new FileOutputStream("cc_numbers")));
    System.setOut(out);
    [/code]


    Besides that sloppy handling of confidential data we have:

    • Swallowing of any exception…
    • An unnecessary and stupid recursive call (he could easily put the try catch inside the loop).

    ... Yes, stupid code… but the thing that really bugs me and makes me ask WTF is:

    [code language="c#"]
    equalsIgnoreCase("Success!")
    [/code]

    ... Why?... and I mean: Why the F*ck?

  • (unregistered) in reply to Guayo

    ... Yes, stupid code… but the thing that really bugs me and makes me ask WTF is:


    <font face="Lucida Console, Courier" size="2">
    equalsIgnoreCase("Success!")
    </font>
     

    ... Why?... and I mean: Why the F*ck?

    BOOLEANS ARE FOR WUSSES! [:|]

  • (unregistered) in reply to
    :
    Leave it to a java programmer to make a VB programmer look smart...


    It's not very hard to make a VB programmer look smart. The bar is kinda low.[li]
  • (unregistered)

    So simple...so clear...so transparent...and yet so, so wrong...

  • (cs) in reply to skicow
    skicow:
    I guess this programmer subscribes to the old adage - "If at first you don't succeed, try, try again."

    Hehehehe.
  • (cs) in reply to
    :
    My guess would be that they put the nasty busy-wait code into production, it failed with an uncaught exception, and then they "fixed" it.
    And so if the file check caused an exception, it will denounce and deny, declaring everything "all lies!" and run another check.... forever.

    [Y]
  • (cs)

    <font style="BACKGROUND-COLOR: #efefef">Why does this method even need to return anything, seeing as it is either going to return "Success!" or just blow up with a Stack Overflow, it might aswell be void.
    WTF!

    Oh, and I love the use of equalsIgnoreCase, even though you know it can only ever return one thing, and you know full well what the capitalisation is!</font>

  • (unregistered)

    I just love how it returns a String instead of a simple boolean. Can't trust those basic data types!

  • (unregistered) in reply to

    The simplest and easiest way would be:
    File file = new File(whatever);
    try{
        while (!file.exist()){
            Thread.sleep(1000);
        }
        return true;
    }
    catch(InterruptedException){}
    return false;

    The InterruptedException will be thrown BTW if the Thread is interrupted from the outside, which generally is not happening.

    This method of course never returns, if the other system is not running any more, so there is no kind of timeout. But the original method doesn't that either.


    Regards, Lothar

  • (cs)

    I love this part:

    if (!waitForCreditCardProcessing(cardNumber,expDateMonth,expDateYear).equalsIgnoreCase("Success!"))

    As if this function ever returns any other value... WTF, didn't you notice that this function either crashes into ExceptionLand or else always returns "Success!"??? It's not a WTF that he compares it in a case-insensitive way. It's not a WTF that he doesn't use a boolean instead. It's a WTF because he checks the result and the result can only be one single value!!!

  • (unregistered) in reply to
    Still any programmer or IT staff member that "architects" this kind of "solution" should be shot and pissed upon.

    That opinion is fine if you get to design the entire system, but more often than not that's not the way it works in real life. There are cases (say, client uploading a file) where polling a directory is the only reasonable course of action.

  • Tom (unregistered) in reply to

    But not THIS way. This is an atrocity. I mean, the recursion alone...

  • Me (unregistered)

    That's even worse! Since blowing the stack is a Throwable, it blows the stack, then starts again!

Leave a comment on “java.lang.HowBigIsMyCallStackException”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article