méthode null-retour d'emballage en Java avec l'option à Scala?

Question

Supposons que j'ai une méthode session.get(str: String): String mais vous ne savez pas si elle vous renvoie une chaîne ou une valeur nulle, car il vient de Java.

Y at-il un moyen plus facile de traiter cette Scala au lieu de session.get("foo") == null? Peut-être un peu de magie appliquer comme ToOption(session.get("foo")) et je peux le traiter de manière Scala comme

ToOption(session.get("foo")) match {
    case Some(_) =>;
    case None =>;
}

Answer 1

La méthode de Option de l'objet compagnon apply sert une fonction de conversion de références nullables:

scala> Option(null)
res4: Option[Null] = None

scala> Option(3)   
res5: Option[Int] = Some(3)

Answer 2

L'objet Option a une applymethod qui fait exactement cela:

var myOptionalString = Option(session.get("foo"));

Answer 3

Notez que lorsque vous travaillez avec des objets Java, il ne fonctionnera pas comme prévu:

val nullValueInteger : java.lang.Integer = null
val option: Option[Int] = Option(nullValueInteger)
println(option)  // Doesn't work - zero value on conversion

val nullStringValue : String = null
val optionString: Option[String] = Option(nullStringValue)
println(optionString) // Works - None value

Answer 4

Ceci est un très vieux sujet, mais un beau un!

Il est vrai que la conversion de tout résultat non-exception Essayez d'option se traduira par une partie ...

scala> Try(null).toOption
res10: Option[Null] = Some(null)

... parce que Try est pas vérification mais juste valeur NULL de façon à gérer fonctionnellement exceptions.

Utilisation Essayez d'attraper une exception et la conversion à une option que pour la commodité n'affiche Aucun en cas d'exception se produit.

scala> Try(1/0).toOption
res11: Option[Int] = None

Vous voulez préserver les valeurs qui sortent de Try. Cela peut être nulle.

Mais il est vrai aussi que la lib standard est assez déroutant parfois ...

scala> Try(null).toOption
res12: Option[Null] = Some(null)

scala> Option(null)
res13: Option[Null] = None

Ce comportement est incompatible peu, mais ce genre de reflète l'utilisation onformément à la fois Essayez et Option.

Vous utilisez essayer d'obtenir ce qui sort d'une expression qui peut lancer des exceptions, et vous ne se soucient pas de l'exception elle-même.

La valeur qui peut sortir peut très bien être une valeur nulle. Si toOption a None, vous ne pouviez pas Différencier entre une exception et une valeur NULL , et ce n'est pas assez!

autonome, vous utilisez l'option pour encapsuler l'existence ou non de quelque chose. Donc, dans ce cas, certains (null) est None, et qui a du sens, parce que nul dans ce cas représente l'absence de quelque chose. Il n'y a pas d'ambiguïté ici.

Il est important de remarquer que, dans tous les cas, la transparence referencial est pas cassé depuis .toOption est pas le même que l'option ()

Si vous avez vraiment besoin de faire respecter DEUX sécurité d'exception Sécurité null et votre code ne vraiment vraiment pas besoin de différencier entre les nuls et une exception , il vous suffit de combiner les deux paradigmes! Parce que le bien, c'est ce que vous voulez, non?

Vous pouvez le faire d'une façon ...

scala> Try(Option(null)).getOrElse(None)
res23: Option[Null] = None

scala> Try(Option(3/0)).getOrElse(None)
res24: Option[Int] = None

scala> Try(Option(3)).getOrElse(None)
res25: Option[Int] = Some(3)

... ou d'une autre ...

scala> Try(Option(null)).toOption.flatten
res26: Option[Null] = None

scala> Try(Option(3/0)).toOption.flatten
res27: Option[Int] = None

scala> Try(Option(3)).toOption.flatten
res28: Option[Int] = Some(3)

... ou la plus laide ridiculement d'entre eux anothers ...

scala> Option(Try(null).getOrElse(null))
res29: Option[Null] = None

scala> Option(Try(3/0).getOrElse(null))
res30: Option[Any] = None

scala> Option(Try(3).getOrElse(null))
res31: Option[Any] = Some(3)