Почему в реализации метода `unapply` для case-классов есть проверка 'null`? - PullRequest
2 голосов
/ 27 мая 2019

Я работаю над заменой метода unapply на объекте-компаньоне класса case моей собственной реализацией. И после изучения множества различных касательных, связанных с реализацией unapply, кажется, что в большинстве из них есть защита null, как в сгенерированном компилятором коде, так и в реализациях, где он явно переопределяется. Код из сгенерированного компилятором кода для unapply выглядит примерно так (некоторые из них используют eq вместо ne):

def unapply(location: Location): Option[(Double, Double)] =
  if (location ne null)
    Some((location.longitude, location.latitude))
  else
    None

Учитывая, что не должно быть абсолютно никакого использования null в чистом (т.е. идиоматическом) Scala-коде, почему выполняется эта проверка null? Имеет ли это какое-то отношение к взаимодействию с Java (поскольку Java по-прежнему увлекается использованием null), просачивающимся в метод unapply? Какие нежелательные последствия будут иметь место, если я уберу проверку, потому что я исключил возможность того, что экземпляр класса case, в который передается метод unapply, может быть нулевым или недействительным? Итак, какой вред замены вышеуказанной реализации на эту?

def unapply(location: Location): Option[(Double, Double)] =
  Some((location.longitude, location.latitude))

1 Ответ

1 голос
/ 28 мая 2019

В противном случае это может привести к удивительному поведению:

nullableJavaMethod() match {
  case Location(lat, long) => "Handle location here!"
  case null => "Handle null here!"
}

Вы можете предпочесть другой подход к обработке пустых значений, но это не означает, что вы должны создавать такие случаи, как описанный выше сбой с NPE, если кто-то этого предпочитает.подход.Обратите внимание, что это относится только к unapply, так как другие методы не будут страдать от проблемы, описанной выше.

...