Using generic records in record patterns 2 – Record and record pattern

This time, if we call buyFruit(seed) we get the message, This is a seed of Fairytale from India. The call matches the case SeedRecord(String type, String country) branch. And, if we call buyFruit(eggplant) then we get the message, This is a Fairytale eggplant. The call matches the case EggplantRecord(SeedRecord seed, float weight) branch. There are no surprises so far!Now, let’s have an edge case. We assume that SeedRecord is null and we create the following “bad” eggplant:

EggplantRecord badEggplant = new EggplantRecord(null, 300);

The call buyFruit(badEggplant) will return a NullPointerException containing the following crystal clear message: java.lang.NullPointerException: Cannot invoke “modern.challenge.SeedRecord.type()” because “seed” is null. As you can see, in the case of nested null the compiler cannot prevent the execution of the corresponding branch. The nested null doesn’t short-circuit the code and hits the code of our branch (case EggplantRecord(SeedRecord seed, float weight)) where we call seed.type(). Since seed is null we get a NullPointerException.We cannot cover this edge case via a case such as case EggplantRecord(null, float weight). This will not compile. Obviously, a deeper or wider nesting will complicate these edge cases even more.Let’s see what happens in the case of using instanceof instead of switch. So, the code becomes:

public static String buyFruit(Fruit fruit) {
      
  if (fruit instanceof SeedRecord(
      String type, String country)) {
     return “This is a seed of ” + type + ” from ” + country;
  }
  if (fruit instanceof EggplantRecord(
      SeedRecord seed, float weight)) {
    return “This is a ” + seed.type() + ” eggplant”;
  }             
  if (fruit instanceof MelonRecord(
      SeedRecord seed, float weight)) {
    return “This is a ” + seed.type() + ” melon”;
  }                              
  return “This is an unknown fruit”;
}

In case of instanceof there is no need to add explicit null checks. A call such as buyFruit(null) will return the message, This is an unknown fruit. This is happening since no if statement will match the given null.Next, if we call buyFruit(seed) we get the message, This is a seed of Fairytale from India. The call matches the if (fruit instanceof SeedRecord(String type, String country)) branch. And, if we call buyFruit(eggplant) then we get the message, This is a Fairytale eggplant. The call matches the case if (fruit instanceof EggplantRecord(SeedRecord seed, float weight)) branch. Again, there are no surprises so far!Finally, let’s bring in front the badEggplant via the buyFruit(badEggplant) call. Exactly as in the case of switch example, the result will consist of a NPE: Cannot invoke “modern.challenge.SeedRecord.type()” because “seed” is null. Again, the nested null cannot be intercepted by the compiler and the if (fruit instanceof EggplantRecord(SeedRecord seed, float weight)) branch is executed leading to a NullPointerException because we call seed.type() while seed is null.Trying to cover this edge case via the following snippet of code will not compile:

if (fruit instanceof EggplantRecord(null, float weight)) {
  return “Ops! What’s this?!”;
}

So, pay attention that nested patterns don’t take advantage of case null or of the JDK 19+ behavior that throws an NPE without even inspecting the patterns. This means that null values can pass through a case (or instanceof check) and execute that branch leading to NPEs. So, avoiding null values as much as possible should be the way to a smooth road ahead.