4 ms·

A null pointer exception is a bug that breaks business logic. There's no "business logic instead of language stuff" because the language stuff is the foundation

A null pointer exception is a bug that breaks business logic. There's no "business logic instead of language stuff" because the language stuff is the foundation that business logic rests on. If you don't test against failure modes, what's even the point in testing?

maxbond 3y ago
To close the loop, Rust doesn't include a `null` type and you wouldn't encounter something comparable in idiomatic Rust (because you'd be using eg Option::map to handle None cases gracefully), so this is a class of test that would be common in Java and C that is close to irrelevant in Rust.
- tialaramex 3y ago
  To be more specific, Rust does have among other things: std::ptr::null() - an actual null pointer, probably the zero address on your hardware, and this isn't even an unsafe function. On the other hand, you won't find many uses for a null pointer so, I mean, congrats on obtaining one and good luck with that. std::ptr::null_mut() - a mutable null pointer, similarly unlikely to be of any use to you in safe Rust, but also not an unsafe thing to ask for. But, these are pointers, so they're not values that say, a String could take, or a Vec<String> or whatever, only actual raw pointers can be null.
  - pornel 3y ago
    And even for raw pointers you can use NonNull<T>.
  - deleted 3y ago
    [deleted]
- benibela 3y ago
  Still someone might call unwrap on an Option and then run into some kind of null pointer exception
  - maxbond 3y ago
    Sure, you can panic unwrapping a None, but there are two important distinctions. First, this is a controlled panic, not a segmentation fault. The language is ensuring that we don't access the null pointer, or an offset from the null pointer. Null pointer access can be exploitable in certain circumstances (eg, a firmware or kernel). Your use of "exception" suggests you're thinking about it in Java terms however, and Java is equivalent here. Second, you can only encounter this in explicit circumstances, when you have an Option<T>. Wheras in languages with a null type, any variable can be null implicitly, regardless of it's type.
    - benibela 3y ago
      >First, this is a controlled panic, not a segmentation fault. But a segmentation fault is also controlled >Your use of "exception" suggests you're thinking about it in Java terms however, and Java is equivalent here. No, I am thinking in Delphi terms. It is overspecialized to Windows userspace. Windows gives an Access Violation, and that can be caught, and Delphi throws it as exception >Second, you can only encounter this in explicit circumstances, when you have an Option<T>. Wheras in languages with a null type, any variable can be null implicitly, regardless of it's type. Delphi has both nullable types and null-safe types
      - maxbond 3y ago
        > But a segmentation fault is also controlled A segmentation fault may not happen (which is to say, we may corrupt memory or worse) if the null pointer is mapped into memory (as in an embedded or kernel context) or if it's accessed at a large offset, which results in a pointer that's mapped into memory. This may be rotten luck or it may be exploited by an attacker. > No, I am thinking in Delphi terms. Fair enough, I don't know Delphi. I'll take what you're saying about it as read.
rightbyte 3y ago
A null pointer exception is a free runtime check. I really don't understand the fuss about null. The "most expansive design mistake in computer science" and whatever.
- Sharlin 3y ago
  Free runtime check of what? The point is that if nulls don't exist, there is no need for a "check". Runtime or otherwise. If I write a type that models Foo, I want it to model Foo and not "Foo or null". If I want to model "Foo or no data" then I use a separate type that makes my intention clear (in Rust spelled `Option<Foo>`). Languages where nothing is precisely Foo and everything is "oh by the way this is only possibly Foo" are deeply, deeply flawed.
dgb23 3y ago
If an exception breaks business logic, then you can test the code by testing business logic. How do null pointer exceptions arise? Inconsistent data: you have code paths that implicitly assume invariants. Trivial cases like “this field is not provided” and more complex ones like “these fields have a specific relationship”. You can often move those assumptions into the data structure in any language. Then your tests become a matter of generating and transforming data from a holistic perspective instead of micromanaging individual code paths.

maxbond 3y ago

To close the loop, Rust doesn't include a `null` type and you wouldn't encounter something comparable in idiomatic Rust (because you'd be using eg Option::map to handle None cases gracefully), so this is a class of test that would be common in Java and C that is close to irrelevant in Rust.

tialaramex 3y ago
To be more specific, Rust does have among other things: std::ptr::null() - an actual null pointer, probably the zero address on your hardware, and this isn't even an unsafe function. On the other hand, you won't find many uses for a null pointer so, I mean, congrats on obtaining one and good luck with that. std::ptr::null_mut() - a mutable null pointer, similarly unlikely to be of any use to you in safe Rust, but also not an unsafe thing to ask for. But, these are pointers, so they're not values that say, a String could take, or a Vec<String> or whatever, only actual raw pointers can be null.
- pornel 3y ago
  And even for raw pointers you can use NonNull<T>.
- deleted 3y ago
  [deleted]
benibela 3y ago
Still someone might call unwrap on an Option and then run into some kind of null pointer exception
- maxbond 3y ago
  Sure, you can panic unwrapping a None, but there are two important distinctions. First, this is a controlled panic, not a segmentation fault. The language is ensuring that we don't access the null pointer, or an offset from the null pointer. Null pointer access can be exploitable in certain circumstances (eg, a firmware or kernel). Your use of "exception" suggests you're thinking about it in Java terms however, and Java is equivalent here. Second, you can only encounter this in explicit circumstances, when you have an Option<T>. Wheras in languages with a null type, any variable can be null implicitly, regardless of it's type.
  - benibela 3y ago
    >First, this is a controlled panic, not a segmentation fault. But a segmentation fault is also controlled >Your use of "exception" suggests you're thinking about it in Java terms however, and Java is equivalent here. No, I am thinking in Delphi terms. It is overspecialized to Windows userspace. Windows gives an Access Violation, and that can be caught, and Delphi throws it as exception >Second, you can only encounter this in explicit circumstances, when you have an Option<T>. Wheras in languages with a null type, any variable can be null implicitly, regardless of it's type. Delphi has both nullable types and null-safe types
    - maxbond 3y ago
      > But a segmentation fault is also controlled A segmentation fault may not happen (which is to say, we may corrupt memory or worse) if the null pointer is mapped into memory (as in an embedded or kernel context) or if it's accessed at a large offset, which results in a pointer that's mapped into memory. This may be rotten luck or it may be exploited by an attacker. > No, I am thinking in Delphi terms. Fair enough, I don't know Delphi. I'll take what you're saying about it as read.

rightbyte 3y ago

A null pointer exception is a free runtime check. I really don't understand the fuss about null. The "most expansive design mistake in computer science" and whatever.

Sharlin 3y ago
Free runtime check of what? The point is that if nulls don't exist, there is no need for a "check". Runtime or otherwise. If I write a type that models Foo, I want it to model Foo and not "Foo or null". If I want to model "Foo or no data" then I use a separate type that makes my intention clear (in Rust spelled `Option<Foo>`). Languages where nothing is precisely Foo and everything is "oh by the way this is only possibly Foo" are deeply, deeply flawed.

dgb23 3y ago

If an exception breaks business logic, then you can test the code by testing business logic. How do null pointer exceptions arise? Inconsistent data: you have code paths that implicitly assume invariants. Trivial cases like “this field is not provided” and more complex ones like “these fields have a specific relationship”. You can often move those assumptions into the data structure in any language. Then your tests become a matter of generating and transforming data from a holistic perspective instead of micromanaging individual code paths.