Hacker News Reader

Comment by jlujan | Hacker News Reader

presumably, as a programmer, you check return values. Especially if they could be a null reference

Any reference in Java can be null, as is the case in most languages. So developers only check the ones they know "could" be null, in normal operation. If you only distribute your app via the Play Store, attempting to access it will never fail, thus there's no more point in checking for null pointers than there is in checking the result of String.split: it will never fail, short of something wacky and unexpected like a broken JVM.

> So developers only check the ones they know "could" be null, in normal operation.

Not the good ones. Normal operation isn't when you're dealing with a mobile device, there could be any number of reasons why your app can't reach a certain service delivered by some API so better to be prepared for that eventuality.

Yes, a good programmer writes a robust application, but ignoring the specifics of this case is being entirely disingenuous. If I write an app to use the Play API and only distribute it via the Play Store then there is no good reason for me to spend my time writing `if (foo != null)` all over the place to placate someone trying to circumvent the official way of downloading my application.

You have to balance the tradeoffs of bloated code and pointless error checking with adding features and improving the program. The more error checking code one writes the more one must maintain and the higher the potential for bugs.

> The more error checking code one writes the more one must maintain and the higher the potential for bugs.

That's an artifact of the chosen environment. Not checking for errors in that environment is a bug.

Artifact or not, it's still something one must maintain. Not checking for errors is not a bug, it is you choosing to not support a fringe group of users because it is worth your time and effort. You can call it whatever you like, but that is the reality of the situation. There are tradeoffs to be made and code to be maintained.

I don't think it is a matter of not being able to reach Google the network service but the Google provided services that run on the phone (they may well then access the network and provide useful error messages that you fully handle). It is more like a case of a missing library than a loss of network connectivity. There is a good argument that you should always check anyway but there is also the argument that the app is only designed to run on devices with the Google Play services installed and that you only sell it that way so anyone without must be pirating anyway.

Besides that what do you do to handle the loss of something your app requires as a basic service? A nice error beats NullPointer but not by much.

Actually the way you check for Google Play services doesn't involve nulls at all, it's a status code.

And related to null-checking, I took the pervasive approach in one of my apps for fun. It's hilarious - almost 1/3 of my app is checking if something is null. Makes you wish for a switch to a language where nulls don't exist unless explicitly asked for.

Not always. If you use maps, for instance, then calling getMap on a map fragment when Play Services isn't installed will give you back a null reference.

Reply on news.ycombinator.com