• I shouldn't be here (unregistered)

    -1st!

  • Naomi (unregistered)

    TRWTF is that this article doesn't have next or previous links!

  • Vicki (unregistered)

    Because they were labouring under a coding standard that mandated some form of idiocy, and this form was the most palatable?

  • Best Of 2021 (unregistered)

    They're almost certainly doing this to get the call stack logged. It is a WTF, but only a fairly minor one caused by ignorance of Thread.getStackTrace - or maybe this code is older than Java 1.5 (you didn't always used to be able to avoid using an exception to get it iirc).

    Hopefully as well as submitting this here, the OP also made sure the author of the code was informed about the better way.

  • Maia Everett (github)

    Even if they were limited to Java 1.4, there was no need to actually throw the exception. log.debug(...., new Exception()) would have done just fine.

  • doubtingposter (unregistered) in reply to Maia Everett

    The reason why abusing exceptions is bad is because creating the stacktrace is really expensive. If you've already made the exception, the actual throwing doesn't really matter.

    If you're going to accept the cost of a stacktrace, a "throw new Exception()" wouldn't have made me cringe too hard.

    Also, I had to look up what doubleValue() actually does - it's an explicit cast-to-double operation, for whatever reason. Nothing to do with doubling a value.

  • Lothar (unregistered)

    Most logging frameworks in Java have a log(String message, Throwable cause) method. I'm not aware of one with a log(String message, StackTraceElement[] causeStack). I've got no explanation of the actually throwing and catching of that exception, though.

  • Naomi (unregistered) in reply to Naomi

    TRRWTF is that now it does, a year and change after the fact!

  • Naomi (unregistered) in reply to doubtingposter

    it's an explicit cast-to-double operation, for whatever reason.

    In brief, there's an interface called java.lang.Number, which provides an xValue method for each of the six number primitives. It's implemented by the boxed primitives (Integer, Double, and the like), as well as the atomic and big number classes. It's not that useful, but that's the reason.

    Ordinarily you'd just use typical casting notation - (double) i - but there's nothing "ordinary" about this code, anyway.

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered)

    Ironically, this is one of the specific cases where the HotSpot JVM can choose to omit the stack trace from the NullPointerException for optimization purposes:

    https://stackoverflow.com/questions/58696093/when-does-jvm-start-to-omit-stack-traces

  • Splatmandex (unregistered)

    Very early in my coding career I wanted to be able to generate a stack trace of all threads states on demand (w/o using gdb) to diagnose a hangup in the field. So I made a special remote API call that would force a NULL ptr dereference. The OS (early release of OSX circa y2k) would generate a nice little crash log for me with all the data I wanted. I cringe at that now. (After figuring out the problem the API was removed)

  • eric bloedow (unregistered)

    i seem to remember an old story about a program that worked fine in Debug mode but not in normal mode...i forget the details.

  • Sole Purpose Of Visit (unregistered) in reply to Anonymous') OR 1=1; DROP TABLE wtf; --

    So ... for once, doing it completely the wrong way results in completely the wrong output?.

    I find this strangely comforting.

  • Is That Really A Crosswalk? (unregistered)

    Once again the WTF can be explained away if the age of the code is known - seems a lot is complaining about code that was written before a feature existed.

  • Sole Purpose Of Visit (unregistered) in reply to Is That Really A Crosswalk?

    See Maia Everett's comment. A WTF is a WTF.

  • mihi (unregistered)

    I've seen similar code with ((String)null).toString() to get a NullPointerException with stack trace to pass to the logging method. Replaced that one with new Throwable("For stack trace"). It made both the code and the logs much clearer; It was Java 1.1.

  • ooOOooGa (unregistered) in reply to Sole Purpose Of Visit

    Yeah. Even if what doubtingposter says is accurate and the bulk of the cost of an exception is creating the exception in the first place. Without throwing the exception, the intent of the code is more clear. And could be more easily and confidently replaced with something that will just log the stack trace later.

  • ooOOooGa (unregistered)

    Or even just create a new NullPointerException() and then throw it. No need to actually dereference a null variable.

  • van Dartel (unregistered)

    If the code does what the names of the variables and functions suggest, it is only used to trace execution times per stack depth and initial instruction.

    Never mind the (lack of) elegance of the actual code; why would anybody be interested in the raw data it produces?

    This truly makes it an exceptional mystery, which is further substantiated by the fact that it first appeared on CodeSOD on 2007-04-04: back then nobody could come up with a "that-must-be-it"-explanation too. Perhaps it's time to finally settle on the conclusion that "it just lacks sense" and move on.

  • Ruts (unregistered) in reply to ooOOooGa

    I'd be surprised if 'creating the exception' was slow, as I'd think at that point it is just another POJO.

    One might possibly create an Exception object and throw it from numerous places in the code, for which one could expect the stacktrace to indicate the line it was thrown from, not the line it was created/instantiated on.

    I would expect and assume (and maybe make an ass) that the stacktrace is only generated as part of the throw and not the new

    Then again, I wouldn't do this so my assumptions may well be completely off the mark.

  • Goth (unregistered)

    My favorite:

    *0();

    In the old days, Sun would segfault. Dec would reboot.

Leave a comment on “Double Your Value”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article