Hacker News Reader

Comment by pohl | Hacker News Reader

I'd like to have a dollar for every time I've seen a NullPointerException on some line that was constructed by someone who loves the list of methods that automagically pops up for the dot operator:

  foo.bar().baz().qux()

...Grrrrr!

View on HN

If only there was some combinator for sequencing computations... then you could write:

   foo >>= bar >>= baz >>= quux

and there would never be a NullPointerException, because the >>= function could react appropriately when null was encountered!

You win at the "Most Subtle Haskell Reference" in this conversation.

Since I don't know haskell, I'll throw out that groovy does this too.

foo?.bar()?.baz?.quux

What other languages have this kind of shortcut?

CoffeeScript: http://jashkenas.github.com/coffee-script/#existence

Since coffeescript was mentioned, the Ruby andand library is also frequently mentioned when this comes up. (I only ruby for Rake).

  $ irb
  >> def nil.method_missing *args
  >>   nil   
  >>   end 
  => nil
  >> a = nil
  => nil
  >> a.b.c.d
  => nil
  >>

You know what's even better? When someone who writes that style of code (in C++, no less!) knows that one of the intermediate values could be null, so they use a set of macros involving setjmp and longjmp, and trap SIGFPE, all to implement a fragile sort of try/catch for null de-references.

Clever? Insane? Horribly un-portable and prone to breakage depending on compiler, libc, and OS versions? All of the above!

(And yes, I have seen this coding style used in multiple projects at a major corporation. It was a favorite of a coder-turned manager, which means it tended to sneak in on any project he supervised.)

Clever? Insane? Horribly un-portable and prone to breakage depending on compiler, libc, and OS versions? All of the above!

Yeah, you already said it was C++.

And thus, the Maybe monad was born.

Try catching a block that does that is actually less code than a long set of conditionals. Granted it's basically saying:

  if (foo != null) if (bar.bar() != null) if (foo.bar().baz() != null) {
  ...
  worked = true;
  }
  if (false == worked ) {/*to do*/}

But, staying on the happy path until you can demo something is often useful. I think the problem is how you transition from demo to production worthy code.

if (foo!=null && (a = foo.bar()) && a != null && ...

a = foo.bar() will always evaluate to true as the assignment shouldn't ever fail. Of course, in compiled languages I'm sure there will need to be a declaration of 'a' but if there is a possibility to reuse temp variables then could work.

However, if you are coding in C/C++ (and to a similar extent Java, there really is no way around it.

This could be an example of why hybrid functional, imperative, and object oriented languages are becoming popular because the programmer can pick the paradigm that most suits the problem.

That's not the same since you are executing the bar method multiple times.

If you really want to get picky, return foo.bar().baz().qux() * 2;

Could become:

  Bar bar = foo.bar();
  if(bar == null) handleBarNull();
  else { 
     Baz baz = bar.baz();
     if(baz == null) handleBazNull();
     else { 
        //(assuming qux is a value)
        return baz.qux() * 2;
     }
  }

That might be the correct way to write that code if the situation is not recoverable.

Say you have

    public int doubleFooBarBazQux(Foo foo) {
      return foo.bar().baz().qux() * 2;
    }

That might throw a NPE, but what's the alternative?

I typed this into Eclipse, and it's super-awesome-excellent auto-code-writer decided that it should be:

   public int doubleFooBarBazQux(Foo foo) throws NullPointerException {
     try {
        return foo.bar().baz().qux() * 2;
     }
     catch(NullPointerException e){
        throw new NullPointerException(e.getMessage());
     }
   }

If only there was a right-click option for "improve quality"...

Yeah, the generated code is asinine, but what would you prefer? "Improve quality" in this case would just leave out the try/catch altogether. Is there another behavior that would be better, given that we know nothing about foo, bar, baz, or qux?

You'd be starting the 'Pohl foundation for old programmers' from the proceeds before long, I gather.

Code like that is really common, and, unfortunately, so are blank 'catch' sections.

Reply on news.ycombinator.com