Question

我是一位相当新的Scala开发人员。我是一名经验丰富的Java开发人员，到目前为止，我一直很喜欢Scala的简单性。我非常喜欢功能结构，并且经常强迫你编写更清晰的代码。然而，最近我注意到由于舒适和简单，我最终使用的结构我不一定在Java中使用，实际上被认为是一种不好的做法，例如。

private def convertStringToSourceIds(value: String) : Seq[Integer] = {
    Try(value.split(",").toSeq.map(convertToSourceId(_))).getOrElse(Seq())
}

相同的代码段可以写为

private def convertStringToSourceIds(value: String) : Seq[Integer] = {
    if(value!=null) value.split(",").toSeq.map(convertToSourceId(_)) else Seq()
}

我的一部分意识到Try/getOrElse块的设计考虑了Options，但通常它会使代码更具可读性，并处理您可能错过的案例（当然，这不是'＃1}}总是一件好事）。

我很想知道有经验的Scala开发人员对此事的意见。

Answer 1

我没有声称任何＆＃34;经验＆＃34;标题，但我更喜欢你的第二个结构，原因有几个

抛出异常（在这种情况下是NPE）是昂贵的，最好避免;它应该保持原样，例外 al
if是Scala中的表达式，可避免声明＆＃34;悬空＆＃34;用于保存测试结果的变量（就像三元运算符一样）。或者，match..case构造提供了非常易读的代码。
我个人会将Option[Seq[Integer]]返回＆＃34;传回＆＃34; values为null的信息，有助于进一步链接您的功能。

像

这样的东西

private def convertStringToSourceIds(value: String) : Option[Seq[Integer]] = value match {
    case null => None
    case _ => Some(value.split(",").map(convertToSourceId(_)))
}

注1：不确定是否需要toSeq

注意2：无论好坏，看起来有点Haskellish

Scala + FP的组合几乎可以肯定你会得到不同的意见：）

修改请阅读以下评论，了解其他原因和备选方案，即

def convertStringToSourceIds(value: String): Option[Array[String]] = Option(value).map(_.split(",").map(convertToSourceId(_)))

Answer 2

如果可以，请使用build代替Option来显示缺少值的时间。

假设您无法使用null，可以采用更易读的方式处理此问题

Option

Scala：尝试.getOrElse vs if / else

2 个答案: