• drobnox (unregistered) in reply to Someone You Know
    Someone You Know:
    Jake Vinson:
    Working on an application that will only ever be used by the local government in Podunk, MA?

    Podunk is in Michigan. Podunk, MA is actually called "Florida".

    I ran over a raccoon in a rental car in Florida once, while I was driving through Massachusetts.

  • K (unregistered) in reply to JimBob
    JimBob:
    K:
    Then I explained the project lead why there still was one of those bugs left and that we had to remove the last buggy copy and replace it with a call of the method that did things right. His response was, that we were too close to the deadline for such changes, so we just had to fix the bug in the remaining instance of the code instead.
    Ugh. Unless it will take /more/ time to implement a solution like that thus impacting the project schedule - easier to ask forgiveness than permission
    I weren't really asking for permission. We were just discussing the bug (for reasons I don't remember now, perhaps we were just doing a quick run over all the outstanding bugs). And I told what I intended to do about this bug, and was told not to do it. Sure it made me wish I had already done it right. Instead I then had to do it wrong.
  • ha (unregistered)

    The most generic program is AI. But it would refuse to work for such boss ;) .

  • Martin (unregistered) in reply to JimBob
    JimBob:
    He also correctly used "Constant".equals(Variable) instead of the usual novice error of Variable.equals("Constant") to prevent null pointers.
    WTF?! This doesn't prevent null pointers, instead it HIDES real error. This is the same thing as enclosing all code in try/catch and ignoring exception, thinking you "prevented" them!

    Null pointers prevented by proper design and right tools.

    Unless it's valid for usedField[x] to be null. Every time I see someone make a stupid blanket statement like this, I thank FSM that they are not on my project team.

    sigh

    I can't believe a throwaway comment I made about defensive programming against null pointers would spark a Null pointer exception handling holy war.

    But you got it in a nutshell.

    I recently worked with a third party application framework, closed source, that regularly returns null as a valid value.

    It even returned null for a method that returns a collection if it was unable to fill said collection. [I suddenly hear a million Java devs scream out in anguish]

    Not being aware of what type the usedField array is and who fills it, I would naturally code defensively against nulls. At least until I knew more about the codebase in this instance.

    The "Constant".equals(Variable) idiom is the one I use to prevent (avoid/swallow/hide/ignore/whatever) null pointer exceptions from occurring when a variable can validly be a null.

    Alternately you could surround the if-else statements with a single if statement to check for null. But this would increase the indentation and I personally think it looks ugly.

  • (cs) in reply to Franz_Kafka
    Franz_Kafka:
    TopCod3r:
    Is this one of those trolls, or do you actually do this?
    YMBNH.
  • d.k. Allen (unregistered) in reply to JimM
    JimM:
    KenW:
    d.k. Allen:
    The point is that isAwesome() should never be called if s is null -- and I don't mean by having the calling code do the check.
    Amazing! Without knowing the specs for this particular codebase, you can just automatically detect that it's broken! I'm impressed with your abilities.
    You're missing the rtue wonder of d.k.'s comment - somehow the program calling isAwesome() is meant to know that s cannot be null without ever checking it. Prescient codebases? Or Schroedinger's variable? Now that's progress... ;^)

    I did neglect to account for situations where 's' could validly be null - i.e., when we don't have a value (as opposed to the string being empty, which is a different thing). Too much c# coding, I guess. This is certainly a possibility in database apps, however, and the calling code should, in that case, check for null.

    In terms of defensive programming... it depends. An assert is appropriate for some applications. For others (gaming comes to mind) one would just have to envision the outcome of returning 'false' if we did accidentally get a null value in the function - is it better or worse? Either action, true or false, it is probably wrong -- we just want to do the least-wrong thing. And again, I'd use an assert here to catch the possibility of bugs during development (but ensure the assert() is no longer in effect in production code).

    So... for defensive purposes, yeah, okay. Functionally, one should not call foo(s) unless s is non-null. In certain situations {s} /might/ be null, so the calling code would need to check for that. But, for defensive (and keep in mind, this means less-efficient) code, foo() can also check for this.

  • Gnubeutel (unregistered)

    I want to sort the input array lexically by field names because i like order.

    This could all be avoided by using fixed array positions like 98 for Subject, 99 for From and 100 for To.

  • Spudd86 (unregistered) in reply to akatherder

    French?

  • nfl sales (unregistered)

    nfl sales nfl for sales jersey store Christian Louboutin

  • cheap nfl jerseys (unregistered)

    Hi guys!! This is my first website by my self, and i confused that is it good or not made by wordpress or Joomla, i want to choose one 4 me,and give me vsome advice.Thank you! http://www.sportsjerseysshop.com/

Leave a comment on “The Magic Wand of Generic”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article