4 ms·

I don't think the fact that a reasonable course of action in the event of a null type is to do something exception-like implies that having any statement that i

I don't think the fact that a reasonable course of action in the event of a null type is to do something exception-like implies that having any statement that involves something nullable potentially do so is a good thing. It's just that if it's the right thing to do, you should have an active hand in making it do it.

munin 13y ago
I'm kind of willing to debate this. Is the big difference between like: m.foo_meth() // may throw NullPointerException and m = getSomeM() match m with Some x -> x.foo_meth() | None -> raise NullPointerException that in the second case, the exception raising is explicit and in the first it is implicit? I kind of get that I guess, it just seems that it's a similar level of verbosity to deal with it whether or not you allow null pointers and you will, I think, always bottom out to some similar kind of code pattern for error handling...
- comex 13y ago
  The difference is that (a) in a case where failure is supposed to be possible, you are strongly pushed to check for null when it first comes up, rather than just ferrying around the returned object and perhaps getting a NullPointerException five levels into a subsequent function call; (b) in a case where failure is not supposed to be possible, which is probably the majority of cases where NullPointerExceptions come up in practice (since failure is more commonly represented by exceptions or error codes than just null), you have the type system verifying that there is no path through your code that accidentally fails to initialize a variable or otherwise introduces a null. edit: Of course, initialization is not always predictable enough for the type system to verify it, but here functional-ish type systems can help: if your class data looks like "bool connected; Socket socket;", it's possible that you could accidentally end up with connected == true but socket == null, but if you write it as (pseudocode) "state : data Disconnected | Connected (socket : Socket)", with Socket non-nullable, you're assured that it's impossible.
  - munin 13y ago
    those are both big advantages, but neither of them make dealing with the errors easier or more predictable as far as I can tell. it would definitely constrain the locations in your code where there could be surprise though and maybe that's enough?
    - stormbrew 13y ago
      Isn't fewer surprises almost by definition more predictable?

munin 13y ago

I'm kind of willing to debate this. Is the big difference between like: m.foo_meth() // may throw NullPointerException and m = getSomeM() match m with Some x -> x.foo_meth() | None -> raise NullPointerException that in the second case, the exception raising is explicit and in the first it is implicit? I kind of get that I guess, it just seems that it's a similar level of verbosity to deal with it whether or not you allow null pointers and you will, I think, always bottom out to some similar kind of code pattern for error handling...

comex 13y ago
The difference is that (a) in a case where failure is supposed to be possible, you are strongly pushed to check for null when it first comes up, rather than just ferrying around the returned object and perhaps getting a NullPointerException five levels into a subsequent function call; (b) in a case where failure is not supposed to be possible, which is probably the majority of cases where NullPointerExceptions come up in practice (since failure is more commonly represented by exceptions or error codes than just null), you have the type system verifying that there is no path through your code that accidentally fails to initialize a variable or otherwise introduces a null. edit: Of course, initialization is not always predictable enough for the type system to verify it, but here functional-ish type systems can help: if your class data looks like "bool connected; Socket socket;", it's possible that you could accidentally end up with connected == true but socket == null, but if you write it as (pseudocode) "state : data Disconnected | Connected (socket : Socket)", with Socket non-nullable, you're assured that it's impossible.
- munin 13y ago
  those are both big advantages, but neither of them make dealing with the errors easier or more predictable as far as I can tell. it would definitely constrain the locations in your code where there could be surprise though and maybe that's enough?
  - stormbrew 13y ago
    Isn't fewer surprises almost by definition more predictable?