• (disco)

    And once Neil finally understood finally, they could finally program happily ever after.

    And with "happily ever after" we mean "a constant source for front page articles", right?

  • (disco)

    "tested in the fires of a late afternoon code review"

    Might I suggest that if you are using code reviews as a fiery test then you're doing them wrong? Good code reviews focus on code not people.

  • (disco)
    <!-- HTML generated using hilite.me -->
    try {

    Neil.getInstance().submitCodeToCVS();
} catch (UnreasonableChangeException e) {
Donavan.getInstance().dropJaws();
} finally {
Neil.getInstance().finalize();
}
  • (disco) in reply to colinrosenthal

    Yeah, if you have to schedule for code reviews you're doing it wrong. It's much easier to do them during pull requests.

  • (disco) in reply to Eldelshell

    Dammit :hanzo:

    Somebody found the hidden :wtf: already. Who've guessed it would be the code review?

  • (disco)

    I can't see the WTF here. Experienced developer got something completely wrong, is shown the right way, and accepts that he was wrong. That's not a WTF, that's, well, it should be normal, but here it is really an excellent outcome.

  • (disco)

    Fortunately, Neil wasn’t so set in his ways that he couldn’t correct course when proven wrong

    HIRE THAT MAN!

  • (disco) in reply to flabdablet
    flabdablet:
    Fortunately, Neil wasn’t so set in his ways that he couldn’t correct course when proven wrong

    HIRE THAT MAN!

    i would in a heartbeat (well give him the interview at least) if i knew his contact info.

  • (disco) in reply to accalia
    accalia:
    i would in a heartbeat (well give him the interview at least) if i knew his contact info.

    Well, until he removes all /[0-9]+/s from the codebase because he's heard that magic numbers are wrong.

    Or learns that "coding by exception" is an antipattern and nuke your error handling.

  • (disco)

    Ever the optimist, I love a story with a happy ending. Even very intelligent people make stupid mistakes sometimes, and handling them with grace is a good sign.

  • (disco)

    I finally got around to researching finalizers, second google hit was this: Creating and Destroying Java Objects: Item 7: Avoid finalizers. I "skimmed" through the article and saw this:

    // Manual finalizer chaining
@Override protected void finalize() throws Throwable {
    try {
        ... // Finalize subclass state
    } finally {
        super.finalize();
    }
}

    and thought uhho, (thinking Neil was right). BUT, I then went back and re-read the Article a couple of times, realised that it was given of where and when to use explicit termination instead of finalize().

    There is a moral in this somewhere.....

    Oh, nearly forgot. In the re-reading I noticed this:

    This chapter is from the book
Effective Java, 2nd EditionEffective Java, 2nd Edition
  • (disco) in reply to balazs
    balazs:
    try { Neil.getInstance().submitCodeToCVS(); }

    Not to rain on your parade or anything, but in the meat world creating multiple instances of the same person may be illegal in your jurisidction.

  • (disco) in reply to kupfernigk
    kupfernigk:
    creating multiple instances of the same person may be illegal in your jurisidction.

    Obviously, Neil is a singleton; getInstance() always returns the same instance.

  • (disco)

    Seems to me one big WTF here is Donovan, Mr. Grizzled Java vet, didn't immediately recognize that Neil had gotten confused between final and a finalizer (or a destructor, whatever it's called in Java). That whole "might not run" shoulda been the tip-off.

  • (disco) in reply to JohnL4

    Well, a finally clause might not run either if you SIGKILL the JVM at the exact point in time.

    Programming test:

    try{
    ...
}catch (err){
    throw new Exception('skip final?');
}finally{
    print('I\m sad');
}

    does finally block executes?

  • (disco) in reply to loose
    loose:
    Oh, nearly forgot. In the re-reading I noticed this:

    This chapter is from the book Effective Java, 2nd EditionEffective Java, 2nd Edition

    Sometimes the next edition contains improvements/updates, sometimes it contains :wtf:s, and the really fun ones contain both.

  • (disco) in reply to balazs 
    String Neil = "brillant";

    FTFY.

  • (disco) in reply to kupfernigk
    kupfernigk:
    Not to rain on your parade or anything, but in the meat world creating multiple instances of the same person may be illegal in your jurisidction.

    It depends on your method. My parents created two instances of the same person, and although I might have sometimes wished it were illegal, it was not. Indeed, using that method, I think it would be legal everywhere, except perhaps in China. [Tharpa speaks dark truth.]

  • (disco) in reply to Eldelshell

    Pretty sure "yes". [image]

  • (disco) in reply to tharpa
    tharpa:
    My parents created two instances of the same person, and although I might have sometimes wished it were illegal, it was not

    Clarification required (identical twins are not in fact completely identical - apart from the fact that some of them are chimaeras, in other cases environmental variation causes slightly different gene expression, so they are never completely identical. If I call getInstance() on a class, all the instances are initially identical, whereas the differences in gene expression in uniovular twins have already started at the point at which fission occurs into two embryos.)

  • (disco) in reply to HardwareGeek
    HardwareGeek:
    Obviously, Neil is a singleton; getInstance() always returns the same instance.

    in JDBC, getResultSet() on a Statement always annoyed me because the ResultSet is like a quark; although in theory it exists as a separate object, in reality it is an indivisible part of the Statement just as a quark can't be extracted from its hadron (except, of course, by getting things hot enough to create a quark gluon plasma, and I don't know what the computing equivalent is of that. An AI singularity?) Oh dear, too much travelling, it causes my brain to go soft.

  • (disco) in reply to HardwareGeek
    HardwareGeek:
    kupfernigk:
    creating multiple instances of the same person may be illegal in your jurisidction.

    Obviously, Neil is a singleton; getInstance() always returns the same instance.

    Not at all, every call returns a different guy named Neil from the Neil pool.

  • (disco) in reply to foxyshadis

    :wtf::question:

    getInstance() is the Singleton pattern. You're thinking of the Factory pattern; that method would be getNew() or something.

  • (disco) in reply to JohnL4
    JohnL4:
    Seems to me one big WTF here is Donovan, Mr. Grizzled Java vet, didn't *immediately* recognize that Neil had gotten confused between `final` and a finalizer (or a destructor, whatever it's called in Java). That whole "might not run" shoulda been the tip-off.

    It's easy to forget they even exist because the best practice for using them is to never use them, at least in Java. You have zero control over when or even if they ever run. When was the last time you actually saw a Java finalizer?

  • (disco)

    To be honest, I forgot those were even a thing. Once upon a time in basic C programming we talked about destructors, but very quickly I learned that if you EVER have to do that yourself, ya done wrong. :fa_rebel:

    I think I accidentally discovered buffer underflows at that point too, and figured out how to crash a program by releasing null...

  • (disco) 
    try {
   neil.codes();
} catch (FinallyBlockFoundException e) {
} finally {
   neil.getsIt();
}
  • (disco) in reply to Tsaukpaetra
    Tsaukpaetra:
    Once upon a time in basic C programming we talked about destructors, but very quickly I learned that if you EVER have to do that yourself, ya done wrong.

    Huh? C doesn't have destructors, you always have to do everything yourself. Did you mean C++, where you should seldom be manually destroying objects/releasing resources and instead rely on destructors to be run automatically with RAII?

  • (disco) in reply to Protoman

    Right, sorry I didn't qualify that we spent only a few weeks on C before moving on. ;)

  • (disco) in reply to RaceProUK
    RaceProUK:
    :wtf::question:

    getInstance() is the Singleton pattern. You're thinking of the Factory pattern; that method would be getNew() or something.

    Yes and that was in my mind when I wrote it. But there are exceptions even in core lib, like Calendar.getInstance() that returns a Calendar instance initialized with the current date and time.

  • (disco) in reply to accalia
    flabdablet:
    Fortunately, Neil wasn’t so set in his ways that he couldn’t correct course when proven wrong

    I call bulls hit. I haven't met any such "veterans" that were willing to admit that they were wrong. They usually hide behind "You don't know all the details", or even "This is what compiled code does anyway", or some crap like that...

    And that always ends in a stalemate, since they've learned to convince others to the point where they've become self-appointed experts on the topic.

  • (disco) in reply to kupfernigk
    kupfernigk:
    twins

    Fun fact: parents who have twins/multiples call the children that were alone in the womb "singletons".

  • (disco) in reply to kupfernigk

    For identical twins, getInstance() is called twice during pregnancy (obviously). The first time when fertilization occurs; and the second time when the egg splits.

    As the egg splits, the 2 instances are identical.

  • (disco) in reply to Vault_Dweller

    Sounds like forking a spawn to me.

  • (disco)

    Since I share a name with one of the characters in the article, I'd like to take this opportunity to share my favourite abuse of finally:

    int getValueWithDefault(int value)
{
    try {
        value = getValue();
    } finally {
        return value;
    }
}
  • (disco) in reply to urkerab

    Surely you can't return from a finally clause?

  • (disco) in reply to PleegWat
    PleegWat:
    Surely you can't return from a finally clause?

    You can. But you shouldn't. If you were already returning a value or throwing an exception, those disappear into the ether. From the Java Language Spec:

    If the finally block completes abruptly for reason S, then the try statement completes abruptly for reason S (and reason R is discarded).

    and

    If the finally block completes abruptly for reason S, then the try statement completes abruptly for reason S (and the throw of value V is discarded and forgotten).

    Note that a return statement always completes abruptly, and the reason for completing abruptly is the return value; in the case of a thrown exception, the exception object is the reason.

    The same logic applies to throwing a new exception from a finally block — any pending return value or thrown exception is also discarded.

  • (disco) in reply to balazs
    balazs:
    RaceProUK:
    :wtf::question:

    getInstance() is the Singleton pattern. You're thinking of the Factory pattern; that method would be getNew() or something.

    Yes and that was in my mind when I wrote it. But there are exceptions even in core lib, like Calendar.getInstance() that returns a Calendar instance initialized with the current date and time.

    Calendar is such a steaming pile of WTF that misuse of method names probably shouldn't surprise anyone.

  • (disco) in reply to RaceProUK
    RaceProUK:
    `getInstance()` is the Singleton pattern. You're thinking of the Factory pattern; that method would be `getNew()` or something.

    Strictly, all you know is that getInstance() is retrieving an instance, not that it is the only instance (or what the actual class of the instance is). This is Singleton implemented by Factory. (Another way would be to just have a public static final Neil instance field in the class and to assign to that field during the initialisation of the class, with the constructor marked as private so that nothing else can get at it.)

    I hate the way standard object construction works in Java, and the way it forces you to deal with so much pattern shit just to work around it.

  • (disco)

    What I liked most about this one is that I followed the link for the book and read through the discussion about finalizers, and it had this to say:

    So what should you do instead of writing a finalizer for a class whose objects encapsulate resources that require termination, such as files or threads? Just **provide an explicit termination method** [...insert description here...]

    Explicit termination methods are typically used in combination with the try-finally construct to ensure termination. Invoking the explicit termination method inside the finally clause ensures that it will get executed even if an exception is thrown while the object is being used: [code sample]

    So from "finalizers are evil and should never be used; use an explicit termination method inside a finally clause instead", he took away "finally clauses are evil and should never be used".

Leave a comment on “Finally Clear”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article