4 ms·

Here here. I’ve heard “but null pointer errors!” countless times to justify one’s coding approaches (eg, strong typing, Maybe/Optional invasion, this or that PL

Here here. I’ve heard “but null pointer errors!” countless times to justify one’s coding approaches (eg, strong typing, Maybe/Optional invasion, this or that PL, ...) People will murder all kinds of productivity to avoid potential NPEs, when as you say they are generally the easiest bugs in the world to contend with. It is beyond baffling to me, and given how often I hear it, it makes me question the dev world’s sanity.

rmetzler 7y ago
Lately I’ve seen code bases where the Java devs don’t return empty arrays or collections but return null instead. Of course they have to test for null in their calling code. I suggested to return empty collections and objects implementing the NullObject pattern. I think this will make the code more readable, simpler and more secure, but I was answered with skepticism.
- wellpast 7y ago
  Interestingly I agree w/ a preference for empty semantics over null semantics, but NOT for the reason "avoid NPE". Rather, I think minimizing branching/forking in the code logic is how complexity is reduced. For this same reason I don't care for NullObject/Maybe/Optional type approaches which simply do not change the branching forking in your code: if (val == null) { ...logic... } This branching here ^ is not improved at all by a different syntactical representation: ((Optional) val).ifNull(v -> ...logic...) You are still branching, so in my opinion you've made no substantial improvement here. (I can already hear the "but, but..."s.
  - p2detar 7y ago
    I'm dealing with an old code base in which methods tend to process exceptions by catching, logging and returning a null. The dev that wrote this code treated exceptions more like a rare-occurring annoyance rather than a signal for error, thus none of the calling methods had null check branching implemented. The amount of NPEs I had to fix in the past year is astounding. Optional to me is a large leap forward. That being said, I also don't like its verbosity and wish for it to be improved somehow.
    - wellpast 7y ago
      Advocating programming constructs as a kind of ‘policing’ against bad developers doesn’t work for me. It usually ends up at odds with better objectives & heavily taxes conscientious developers, for whom we should really be optimizing things imo.

rmetzler 7y ago

Lately I’ve seen code bases where the Java devs don’t return empty arrays or collections but return null instead. Of course they have to test for null in their calling code. I suggested to return empty collections and objects implementing the NullObject pattern. I think this will make the code more readable, simpler and more secure, but I was answered with skepticism.

wellpast 7y ago
Interestingly I agree w/ a preference for empty semantics over null semantics, but NOT for the reason "avoid NPE". Rather, I think minimizing branching/forking in the code logic is how complexity is reduced. For this same reason I don't care for NullObject/Maybe/Optional type approaches which simply do not change the branching forking in your code: if (val == null) { ...logic... } This branching here ^ is not improved at all by a different syntactical representation: ((Optional) val).ifNull(v -> ...logic...) You are still branching, so in my opinion you've made no substantial improvement here. (I can already hear the "but, but..."s.
- p2detar 7y ago
  I'm dealing with an old code base in which methods tend to process exceptions by catching, logging and returning a null. The dev that wrote this code treated exceptions more like a rare-occurring annoyance rather than a signal for error, thus none of the calling methods had null check branching implemented. The amount of NPEs I had to fix in the past year is astounding. Optional to me is a large leap forward. That being said, I also don't like its verbosity and wish for it to be improved somehow.
  - wellpast 7y ago
    Advocating programming constructs as a kind of ‘policing’ against bad developers doesn’t work for me. It usually ends up at odds with better objectives & heavily taxes conscientious developers, for whom we should really be optimizing things imo.