42 ms·

A null pointer is just a manifestation of a bug, usually unexpectedly missing data. If you can't have nulls, you might have a better chance of spotting the pos

A null pointer is just a manifestation of a bug, usually unexpectedly missing data. If you can't have nulls, you might have a better chance of spotting the possibility of that missing data and trying to deal with it, granted, but if it happens truly unexpectedly the bug is still going to manifest itself somehow, as an NPE or otherwise. Following all the way through, let's say there is no exception anywhere and the missing data gets all the way through to the UI.. well then that's how the bug manifests. Is the missing data just not appearing better than a 'oops, something went wrong' error or similar in response to a 500 caused by an NPE? Depends on the application and circumstances I guess, but in general probably not. The bug exists in both cases. You can present it in better and worse ways, but the bug is that the data is not there and it should be. The point being, not having NPE doesn't fix any problems, fundamentally. It just shifts them elsewhere. No language feature saves you from bugs.

akiselev 7y ago
> The point being, not having NPE doesn't fix any problems, fundamentally. It just shifts them elsewhere. No language feature saves you from bugs. NPE is the problem. The point of type systems with non-nullable references is that they force you to handle the null case explicitly using an Option/Maybe type by throwing a compiler error instead of an exception in production. Nobody expects that getting rid of NPEs would get rid of bugs. It would, however, force one of the most common classes of bugs to be handled when it is cheapest to do so, rather than when the production system is on fire.
- davnicwil 7y ago
  Respectfully I think you're not addressing the point I'm making, but a slightly different one. In the case where a piece of data can be missing, and that's fine, I completely agree that optional/maybe types are useful to model that explicitly and unambiguously. They let you and future maintainters know that this is the case, via the type system, at compile time. But what I'm talking about here is genuine runtime exceptions (which NPE is in Java, of course), where the design of the system says that this piece of data cannot be missing and yet, at runtime, you encounter a case where it is missing, erroneously, because of some bug somewhere. Types like optionals won't help you here, because you wouldn't have used them at design time anyway. The same applies to languages completely without null references. All type systems do is formalise expectations about how data is going to look. If the real data breaks from those expectations because of some bug at runtime, the type system can't help you.
  - RHSeeger 7y ago
    > But what I'm talking about here is genuine runtime exceptions (which NPE is in Java, of course), where the design of the system says that this piece of data cannot be missing and yet, at runtime, you encounter a case where it is missing, erroneously, because of some bug somewhere. My experience is that this is the less common of the cases in a production environment (vs dev where one may be experimenting a bit more).
    - davnicwil 7y ago
      I agree with you :-)
  - deleted 7y ago
    [deleted]
  - boomlinde 7y ago
    > But what I'm talking about here is genuine runtime exceptions (which NPE is in Java, of course), where the design of the system says that this piece of data cannot be missing and yet, at runtime, you encounter a case where it is missing, erroneously, because of some bug somewhere. With checked optionals, you'll know that the code differs from the design at compile time. If a piece of data can indeed be missing you can't compile the code without considering that case explicitly.
jhomedall 7y ago
Most modern languages have an explicit option type, which indicates that a variable may not have a value. Java (and many other languages) allows all reference types to be null, meaning you have little compiler assistance in helping prevent NPEs.
- davnicwil 7y ago
  See my response to the sibling - my point is that optional types are useful as a design tool for writing more robust code that deals with expected missing data as per the design, but don't help at all with actual bugs that cause unexpected missing data at runtime.
  - RHSeeger 7y ago
    Yes and no. Consider that there are functions where returning "no value" (null in our case) is a valid option. It is possible that the callers of those methods forget to check for a null response; leading to a NPE. If the language differentiates between fields/results that can be null and those that cannot, and makes the caller specifically handle the null case, then that cause of NPE will longer happen.
    - davnicwil 7y ago
      I politely suggest you re-read my comments, as I have indeed considered that and it's exactly what I'm saying :-) I agree with what you're saying 100%, I perhaps haven't written clearly enough because I think you're thinking I'm arguing against optionals being useful. I'm not, I'm just saying they're not a solution to the bugs that cause 'real' NPEs - only design bugs where the code doesn't model the data correctly.
      - RHSeeger 7y ago
        I'm not speaking to whether or not you consider optionals useful. Rather, I'm saying that calling a method that can return null without dealing with that case in the code is one of the most common reasons for a NPE. The calling code _is_ the actual error, and forcing the use of optionals removes the possibility of them.
htfu 7y ago
While I'd generally agree it seems like a silly point to argue in this specific case - of course missing data in the UI is much preferable to the entire app becoming unusable! Funny coincidence, by the way. I haven't been on Instagram this past month because the app instantly crashes on launch. On iOS though, and I doubt I've got anyone after me.
- davnicwil 7y ago
  Sure, you're right. It almost always would be. That wasn't the best chosen example for what I was trying to get across!
boomlinde 7y ago
> Is the missing data just not appearing better than a 'oops, something went wrong' error or similar in response to a 500 caused by an NPE? No, but with checked unions like optionals, "not appearing" is a behavior that you explicitly chose to implement. Checked optionals force feed every opportunity to address and amend the error to the programmer. Null pointer exceptions bubble that far up either because the programmers didn't consider all the failure modes caused by implicitly nullable types or because they truly don't care. With checked exceptions, you have limited this to just the "truly doesn't care" category because the programmer is forced to consider every failure mode at every point in the call chain: "not appearing" in that case doesn't happen by mistake but by explicit choice.

akiselev 7y ago

> The point being, not having NPE doesn't fix any problems, fundamentally. It just shifts them elsewhere. No language feature saves you from bugs. NPE is the problem. The point of type systems with non-nullable references is that they force you to handle the null case explicitly using an Option/Maybe type by throwing a compiler error instead of an exception in production. Nobody expects that getting rid of NPEs would get rid of bugs. It would, however, force one of the most common classes of bugs to be handled when it is cheapest to do so, rather than when the production system is on fire.

davnicwil 7y ago
Respectfully I think you're not addressing the point I'm making, but a slightly different one. In the case where a piece of data can be missing, and that's fine, I completely agree that optional/maybe types are useful to model that explicitly and unambiguously. They let you and future maintainters know that this is the case, via the type system, at compile time. But what I'm talking about here is genuine runtime exceptions (which NPE is in Java, of course), where the design of the system says that this piece of data cannot be missing and yet, at runtime, you encounter a case where it is missing, erroneously, because of some bug somewhere. Types like optionals won't help you here, because you wouldn't have used them at design time anyway. The same applies to languages completely without null references. All type systems do is formalise expectations about how data is going to look. If the real data breaks from those expectations because of some bug at runtime, the type system can't help you.
- RHSeeger 7y ago
  > But what I'm talking about here is genuine runtime exceptions (which NPE is in Java, of course), where the design of the system says that this piece of data cannot be missing and yet, at runtime, you encounter a case where it is missing, erroneously, because of some bug somewhere. My experience is that this is the less common of the cases in a production environment (vs dev where one may be experimenting a bit more).
  - davnicwil 7y ago
    I agree with you :-)
- deleted 7y ago
  [deleted]
- boomlinde 7y ago
  > But what I'm talking about here is genuine runtime exceptions (which NPE is in Java, of course), where the design of the system says that this piece of data cannot be missing and yet, at runtime, you encounter a case where it is missing, erroneously, because of some bug somewhere. With checked optionals, you'll know that the code differs from the design at compile time. If a piece of data can indeed be missing you can't compile the code without considering that case explicitly.

jhomedall 7y ago

Most modern languages have an explicit option type, which indicates that a variable may not have a value. Java (and many other languages) allows all reference types to be null, meaning you have little compiler assistance in helping prevent NPEs.

davnicwil 7y ago
See my response to the sibling - my point is that optional types are useful as a design tool for writing more robust code that deals with expected missing data as per the design, but don't help at all with actual bugs that cause unexpected missing data at runtime.
- RHSeeger 7y ago
  Yes and no. Consider that there are functions where returning "no value" (null in our case) is a valid option. It is possible that the callers of those methods forget to check for a null response; leading to a NPE. If the language differentiates between fields/results that can be null and those that cannot, and makes the caller specifically handle the null case, then that cause of NPE will longer happen.
  - davnicwil 7y ago
    I politely suggest you re-read my comments, as I have indeed considered that and it's exactly what I'm saying :-) I agree with what you're saying 100%, I perhaps haven't written clearly enough because I think you're thinking I'm arguing against optionals being useful. I'm not, I'm just saying they're not a solution to the bugs that cause 'real' NPEs - only design bugs where the code doesn't model the data correctly.
    - RHSeeger 7y ago
      I'm not speaking to whether or not you consider optionals useful. Rather, I'm saying that calling a method that can return null without dealing with that case in the code is one of the most common reasons for a NPE. The calling code _is_ the actual error, and forcing the use of optionals removes the possibility of them.

htfu 7y ago

While I'd generally agree it seems like a silly point to argue in this specific case - of course missing data in the UI is much preferable to the entire app becoming unusable! Funny coincidence, by the way. I haven't been on Instagram this past month because the app instantly crashes on launch. On iOS though, and I doubt I've got anyone after me.

davnicwil 7y ago
Sure, you're right. It almost always would be. That wasn't the best chosen example for what I was trying to get across!

boomlinde 7y ago

> Is the missing data just not appearing better than a 'oops, something went wrong' error or similar in response to a 500 caused by an NPE? No, but with checked unions like optionals, "not appearing" is a behavior that you explicitly chose to implement. Checked optionals force feed every opportunity to address and amend the error to the programmer. Null pointer exceptions bubble that far up either because the programmers didn't consider all the failure modes caused by implicitly nullable types or because they truly don't care. With checked exceptions, you have limited this to just the "truly doesn't care" category because the programmer is forced to consider every failure mode at every point in the call chain: "not appearing" in that case doesn't happen by mistake but by explicit choice.