• Joel (unregistered)

    Thread abort exception maybe? Don't know if those exist in Java.

  • Matt Westwood (unregistered)

    Dummy method which is a placeholder for when the object it works on is to gain functionality that may render it invalid and therefore not "alive"?

  • Matt Westwood (unregistered)

    ... or so that subclasses may implement something more sophisticated. Finalize methods also may be there to cleanup any half-formulated database table entries, perhaps.

  • Syntaxerror (unregistered)

    It doesn't really matter if this is in there or not, as the compiler will completly get rid of it.

    The try-block in isAlive() will be optimized away because it'll ALWAYS return true. At this point, isAlive() is replaced by "true".

    Then, the try-block in finalize() is optimized to nothingness, because "if(true) do nothing" doesn't do anything. The try-block follows as above.

    Then, isAlive() will be deleted because it's never used anymore. Same with finalize: There's nothing to do in the finalize-method so we can get rid of it and change the caller of this.finalize() to accomodate the change.

  • The Mole (unregistered) in reply to Syntaxerror

    The compiler won't get rid of it as it is a public method, this means subclasses can override it with their own implementations. My guess is the original author was told the method must return true or false therefore he did an implementation which has returns for true or false.

  • NAME_NOT_FOUND (unregistered)

    You never know when it will return FILE_NOT_FOUND after all...

  • snoofle (unregistered)

    This person learned from TDWTF a long time ago and defensively coded against all possibilities of truth: true... false... FILE_NOT_FOUND <-- there's your exception case

  • CodeNotFound (unregistered)

    Waw :D Double-click on the "false" word at the last article's sentence and see what happen :D

  • (nodebb)

    What about the case where return cannot return true because the calling method did not allocate memory for truthy values? Maybe it can only accept falsy values because these take one bit less to store. In that case it makes sense to return false if you can't return true I think. Granted, this caseis rare and you're better off writing your code always allowing truthy and falsy values. But if you can't control the code calling you, it's good practice to be conservative in what you return.

    In this case the safeguard seems to be superfluous because an if statement can accept a whole boolean as a predicate. But maybe we don't see the whole picture and isAlive() is called from places where only false is accepted as return value. So this is not a WTF. Maybe it errs on the side of caution, but we shouldn't stigmatize people for that.

  • turnsalso (unregistered)

    isAlive never comes back false because it was originally programmed by Rene Descartes.

  • Boaty McBoatface (unregistered) in reply to CodeNotFound

    WTF! Unicorns!

  • Yazeran (unregistered) in reply to Boaty McBoatface

    You must be new here :-)

    there is 2 things you should always do (or not do, your mileage may vary..) with articles from Remy; which is check the page source, and click on everything to get glorious unicorns.... grin

    Plan: To go to Mars one day with a hammer

  • Cube 684B (unregistered)

    It will return false when love is hate, peace is war, and Winston Smith loves Big Brother.

  • Guest (unregistered)

    I believe that you need to review the archives: http://thedailywtf.com/articles/The-Disgruntled-Bomb If a disgruntled developer changes the meaning of if, there's a chance isAlive can catch it.

  • Mike (unregistered) in reply to Yazeran

    I usually use the following "bookmark" in Firefox:

    javascript:(function(){document.getElementsByClassName("article-body")[0].innerHTML=document.getElementsByClassName("article-body")[0].innerHTML.replace(/<!--/g,"<span%20style='color:%20blue'>%20(").replace(/-->/g,")%20");document.getElementsByClassName("article-body")[0].innerHTML=document.getElementsByClassName("article-body")[0].innerHTML.replace('<span%20onclick="cornify_add();return%20false;"%20title="click%20me!">',%20'<span%20style="color:magenta"%20onclick="cornify_add();return%20false;"%20title="click%20me!">');}())
  • Mike (unregistered) in reply to Mike

    Not sure why it duplicated, but ignore that 2nd line...

  • Robert Hanson (unregistered)

    It's been a while since something at TDWFT made me laugh out loud, but this post did. WOW is all I can say.

  • Dmitry (unregistered)

    OutOfMemoryException can in theory make it return false.

  • Daniel Migowski (unregistered)

    We have a similar function called aspectsAreEnabled() which always returns false. This function is then changed by our Aspect framework to return true. This way we are able to determine at runtime if the code running has been visited by the Aspect engine.

  • Russell Judge (google) in reply to Dmitry

    If it runs out of memory trying to return true, there are bigger problems to worry about.

  • Yazeran (unregistered) in reply to Russell Judge

    Yea, I doubt the user will manage to get the returned 'false' and if so he/she/it will likely not manage to get to do anything about it either

  • StephenCleary (unregistered)

    Wondering if it's something weird with remote objects (CORBA, after all). Calling a "heartbeat" method would test whether the remote proxy is still working.

    That said, a method that just returns true would work just as well, since the failure case would always throw.

  • Yevhenii Diomidov (google)

    Maybe this code was just generated by some tool?

  • Simon (unregistered)

    The first method originally called a test, which presumably didn't work. LazyFix- stubbed out test with constant true because the incorrect result broke things if false, and other code would detect error if the service being checked for was not live.

    Winsock had a method to check if that system was ready. It always returned true, with additional text info of "Duh!".
    Even if the subsystem system was not in fact ready.

    A paid MSDN support incident received a response saying that, yeah, it was hard coded, and thanks for sharing.

  • Dan (unregistered)

    "Thread abort exception maybe? Don't know if those exist in Java."

    Java has InterruptedException, but the semantics of when/how it gets thrown would exclude this method from catching it.

    "Dummy method which is a placeholder for when the object it works on is to gain functionality that may render it invalid and therefore not "alive"?"

    That's my guess.

    "Maybe this code was just generated by some tool?"

    It was definitely generated by some tool. Ooooohhhh... You meant a PROGRAM.

  • (nodebb)

    Be honest now: have you started culling Stack Overflow for story ideas?

  • Dr. Frakenstein (unregistered)

    Whence, I often asked myself, did the principle of life proceed? It was a bold question, and one which has ever been considered as a mystery; yet with how many things are we upon the brink of becoming acquainted, if cowardice or carelessness did not restrain our inquiries.

  • (nodebb) in reply to Yevhenii Diomidov

    The original programmer perhaps?

  • thosrtanner (unregistered) in reply to Cube 684B

    Winston does love Big Brother. Even more than he loves Victory Gin. Or Julia. Or Paula Bean.

  • thosrtanner (unregistered) in reply to Syntaxerror

    the code in finalise will likely be optimized out because both the true and false path do the same thing.

  • Scott Christian Simmons (unregistered) in reply to gleemonk

    10/10 for the straight-faced delivery. Totally got me. "Didn't allocate memory for truthy values? WTF? Those don't take any extra memory compared to falsy values! Well, OK, one bit, but ... (Rereads comment, catches reference in second sentence. Slow clap.)

  • maurizio (unregistered)

    The real question is: where is "var1", and what it is used for ?

  • stefandotnet (unregistered)

    What about a coding standard that says that all public/protected functions must have a try/catch. If you have a placeholder function, to be overridden, which only returns true - what would you return in the catch :)

  • guest (unregistered)

    It looks like the thread.IsAlive method in .NET. I bet they were trying to test if a thread was still running, assuming that the method wouldn't be able to return true if it wasn't.

  • SwishWez (unregistered)

    I vote for lazy/cautious fix. I imagine the method did more originally and when the requirement slipped away (perhaps due to a change in environment/infrastructure) the time-pressed/wary author made minimal changes. The fact that there is var 2 suggests there may have been more body with var 1.

  • Dan (unregistered)

    My theory was the less-than-adept programmer saw a call to myObject.isAlive() throw a NullPointerException. "Well, I'll just wrap the method body to catch all exceptions, that should fix it!"

  • Joseph Osako (google)
    No, I haven’t been hanging out in coffee shops wearing a beret and discussing philosophy.

    Mind you, that would be more productive than most programming projects.

  • isthisunique (unregistered)

    I might be able to shed some light on this because I have some similar things in my code.

    alive or isAlive would normally be a heartbeat. Some components inter connect and keep a track of each other with various rules for determining if they are alive themselves which is relayed to other components for graceful behaviour on component outage and for monitoring.

    If creating something simple it might be common to copy and past boiler place but just return true/false rather than add logic immediately. More importantly, people sometimes want to test components during development easily. If a new component is made in a stub or branched for a rewrite then it might have a bit of boiler plate like this so that it doesn't have to depend on other components to be tested.

    Of course it may not be that at all but it's a good chance it might be. I have no idea what the finalise function would be in aid off.

  • Erik (unregistered)

    public boolean isWorldEnded() { return this == null; }

  • Krishna R (google) in reply to Dmitry

    OutOfMemory'Error' is an Error and not Exception, so you won't hit the catch block anyways...

  • Krishna R (google)

    A possibility is a line of code that used to test for liveness and eventually deleted (instead of commenting out)...

    Wildest possibility - a java-agent that injects code at runtime into the try block and the catch block ensures safety.

  • Anonymous (unregistered)

    I agree with the NullPointerException theory: the programmer thought he could catch the exception and use it to return a boolean. Obj.isAlive() was supposed to return true if Obj exists and false if it doesn't. Of course that doesn't work; it always returns true, unless the object really doesn't exist, in which case you still get the exception.

    The thread.isAlive theory was good too. I'm leaning toward the other one, but this is also definitely a possibility.

Leave a comment on “isAlive”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article