• Darkenon (unregistered)

    I think the more likely explanation is that a developer added this to try and fix/debug a null pointer exception and didn't remove it.

  • Lothar (unregistered)

    There actually is a time where ISO8583.this is null (at least if I remember correctly): If bundle() is called during instantiation of the inner class. It's not the case in the code snippet of this article but the original code has been shortened to keep it simpler.

  • my name is missing (unregistered)

    The real WTF to me is a language that states a method returns String but allows you to return null anyway.

  • Pedro (unregistered) in reply to my name is missing

    Why would that be a WTF? String is an object, and any function returning a non-native type can return null. null is a valid string in Java and C#, as apposed to C/C++.

  • Jim Tonic (unregistered)

    Even though ISO8583.this could be null in some rare cases, it's highly dubious that it would have any effect on the function of the bundle method itself. The null could be problematic later on, but then that's the moment to check for nulls.

    Impossible to say for certain without seeing the actual entire code.

  • (nodebb)

    "The null could be problematic later on, but then that's the moment to check for nulls." - The very antithesis of defensive programming. As a related note, if one practices TDD (or some close approximation) then many of the "Defenses" will be created as one builds the tests.

  • Naomi (unregistered) in reply to Pedro

    Why would that be a WTF? String is an object, and any function returning a non-native type can return null. null is a valid string in Java and C#, as apposed to C/C++.

    I know I'm mostly known as the Java fangirl around here, but my background's actually in functional programming - and from that perspective, null is, frankly, bizarre - and Tony Hoare agrees, even though he invented the damn thing! The original idea behind null was that it makes recursive data structures - linked lists, for example - simple to implement - but it's (ab)used all over the place and now every piece of code has to think about how it's supposed to behave when nulls show up.

    Safer languages track "nullability" at compile time. Haskell calls it Maybe, Java calls it Optional, C# has its own system of specifically nullable types that I'm sure someone more familiar with that language could weigh in on - but the post is in Java so I'll use Java's notation. A String is either an instance of the String class or a special null value. An Optional<String> is either a non-null String or a special "empty" value (Optional.empty()). So, obviously, they're very similar. The key difference is that Optional<String> makes it totally clear that you might not have a String, while String itself leaves it ambiguous. In other words, if your code base obeys a convention where everything (possibly excepting private and local variables) is never ever null, you can tell if a value might be missing - and so can the type checker! - just by looking at its type.

    That's why the convention that any reference type is nullable is a WTF. It introduces unnecessary cognitive load and a huge class of bugs that simply have no legitimate reason to even be possible in the first place.

  • SyntaxError (unregistered) in reply to Pedro

    Things that have valid 'empty' values should return those, like collections and strings, instead of null. For those on java 8 or greater, values that don't have a valid empty value I wrap into an optional, such as numbers, custom objects, etc that have the potential of not being able to produce something. The great thing is, it communicates to the next developer, 'hey this may not give you back what you asked for' and then they are forced to handle it. I have for several years now avoided returning null from function calls and have relegated it to its proper position of programmer error, meaning if you got a null pointer exception, go fix your code instead of doing a null check to sweep it under the rug.

  • (nodebb)

    The given codes ample will probably be null or cause an exception anyway. 8538 =/= 8583

  • Your Mammas name (unregistered)

    Looks like code which had a purpose and different values, then the functionality was no longer needed so it was changed to do nothing rather than remove all references to it.

  • Alex (unregistered)

    My favorite kind of WTF, a subtle headscratcher that leads me to learn something new.

  • (nodebb) in reply to Naomi

    A further important consequence of Haskell's Maybe is that if you're wanting the actual string instance then you're forced to acknowledge and handle the null case before proceeding. Again, null pointer exceptions become compile-time errors. I think you can try and get() the value of Optional without checking it has one, and get a NoSuchElementException at run time, which isn't that much of an improvement over a NullPointerException.

  • (nodebb)

    TRWTF is inner class depending on outer class insurance. The outer.this notation is weird.

  • Drak (unregistered)

    "If I were to catalog my biggest failings as a developer, it’s a carelessness around defensive programming. It’s tedious, and it takes work and forethought, and honestly, I just want to get the thing working and see the results. But I recognize it’s important, and work on developing that mindset."

    At uni, we learned that (for private functions) you should not program defensively. You state in the predicate above your function what the input has to conform to. Then if someone gives different input, well garbage in, garbage out. Their problem, not yours. Your function does what it said it would do for valid input.

    Of course, for public functions this is not such a good idea.

  • Jinks (unregistered) in reply to Drak

    Why is it not a good idea for public functions?

    Oh, wait... there's a whole generation of people out there who grew up with languages where anything can have any type and type errors only appear at runtime.

    I think we found the real WTF.

  • Jinks (unregistered)

    PS: I disagree. Checking for null is no more onerous than checking for Maybes or Optionals.

    You still have to check... and I think I'd prefer null-ptr exceptions to happen to lazy coders rather than them steaming ahead with 'wrong' data.

    The idea that code should keep on going no matter what happens seems bone-headed to me. It looks like this WTF was precisely that - an attempt to keep the code going without bothering to find the real problem.

  • Naomi (unregistered) in reply to Watson

    That's true, you can get() the value of an Optional and it will throw a NoSuchElementException if there isn't one. As I understand it, it's intended as an "escape hatch" for situations where "proper" use is impractical. A good example is if you want to use a reduction to implement a method that returns some concrete type - you can't return the Optional, so your only, er, option is to throw an exception. (As of Java 9, there's also an orElseThrow(), which does the same thing with a more explicit name.)

    @Override
Foobar getLargest() {
    return foobars
        .stream()
        .max() // now we've got an Optional<Foobar>
        .orElseThrow();
}

    Optional also has the monadic operations you'd expect (unit is ofNullable(), map is... map(), and join is flatMap() with the identity function), and that's how you're supposed to interact with it.

  • Naomi (unregistered) in reply to Jinks

    It's no more onerous but you have to remember to do it ;) That cognitive load is the problem, not the need to check.

  • Pedro (unregistered) in reply to Naomi

    In C#, reference types are NOT nullable, with the exception of string. Even so, "string" is actually an alias to String (capital S) which is an object, not a reference type per se.

    You can still have nullable<type> for reference types, or shortand like int? , long? , etc.

  • Pedro (unregistered) in reply to SyntaxError

    An empty string is a valid value. A NULL string is the absence of a value. It's extremely useful and an important distinction in many scenarios. An Exception is distinct from null/empty, as it's a processing error.

  • (nodebb) in reply to Pedro

    Exactly this [sorry] . I can't count the number of times I checked for string length only to find it was an empty string of length ONE. Hence the need to return a NULL.

    Also Microsoft Excel: if you never touch a cell, it's totally empty. If you type something into it, then delete everything, that cell is no longer totally "empty" so far as many Excel cell-functions are concerned. I really don't want to know what's hiding behind the spreadsheet.

  • SyntaxError (unregistered) in reply to Pedro

    If you have to return a null string, return an Optional string instead, or throw an exception indicative as to why a valid string could not be returned. Same idea with collections: never return a null collection. It requires the developer using the code to have a deeper understanding of what to expect, when the contract itself should communicate what to expect. Calling isEmpty on a collection returned from a method that COULD return null will yield a null pointer exception. At no point would I expect a null collection. If the parameters I passed in somehow don't make sense to produce output, let me know with an exception telling me why, so I can correct my usage/parameters. same goes for a string: I would never expect a null string to be returned... if your method can't give me a valid string (empty or otherwise), let me know through an exception telling me WHY you couldn't... rather than just null.

  • P. Wolff (unregistered) in reply to Naomi

    I think the problem is not so much a null but that some instance of class A is not an instance of class A if it's the (!) null. If A.null would have all the members its type promises there wouln't be much of a problem.

    A cowboy walks into a bar and NullPointerException at BarCustomer.Speak()

  • David Mårtensson (unregistered)

    I actually managed to get in a similar situation as this code must have come from, using reflection, but in C#.

    I was doing a scripting library that allowed you to bind methods and this required reflection to map arguments so I could get good error messages if the arguments was of the wrong type or number.

    But I managed to use one layer to much and ended up in a situation where "this" was null ;)

    The real code was

    if(a > 0) ...

    And it crashed with null ref exception that I finally tracked down to the reference to a.

    A single local variable "should" never in a situation like this be able to cause null ref especially since it was a simple int (if it was a getter or had some fancy operator overloading it would open for more ways to cause null ref, but I had no such things).

    The cause was that I used reflection to get the function to map arguments, and then to call the function with those arguments ... but in the call I failed to supply the instance of the object :P

    That was a fun problem to troubleshot.

    But I did not add any check for this == null, I rewrote the calling code so that it did not need reflection so the problem would not resurface.

    The real error was I used to much reflection, not only that what was absolutely required for the task.

  • Null Comment (unregistered)

    There is a big difference between "" or [] and null. One says "There is a value stored for this value, and it is empty", and the other says "There is no value stored". For example, imagine a method like getShopsStockingProduct(p). If this returns an empty list, it tells you that no shops have the product. If it returns null, it tells you that it doesn't know.

    Now in some circumstances that should be an exception, but - particularly when dealing with third party systems that may not be connected - sometimes it is reasonable to return 'I don't know' and let consuming code deal with it.

    I do think that since the introduction of nullable types (int? etc in C#), it would be better if "MyClass o" meant 'definitely an instance of MyClass' and MyClass? o allowed it to be null. But there's 50 years of legacy understanding that pointer/reference types are nullable and that should be the default position of any code using or accepting reference values from outside your codebase.

  • Ethan Klein (unregistered)
    Comment held for moderation.
  • ppu-prof_Si (unregistered)

    Наша бригада искусных исполнителей готова предлагать вам новаторские технологии, которые не только обеспечат надежную оборону от холодных воздействий, но и дарят вашему дому стильный вид. Мы практикуем с современными веществами, гарантируя долгосрочный запас использования и выдающиеся результаты. Утепление внешнего слоя – это не то&#1

Leave a comment on “Did You Null This?”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article