【问题标题】:Position information in validation errors验证错误中的位置信息
【发布时间】:2014-03-04 03:06:59
【问题描述】:

问题

我将从一个简化的解析问题开始。假设我有一个字符串列表,我想将其解析为整数列表,并且我想累积错误。这在Scalaz 7 中非常简单:

val lines = List("12", "13", "13a", "14", "foo")

def parseLines(lines: List[String]) = lines.traverseU(_.parseInt.toValidationNel)

我们可以确认它按预期工作:

scala> parseLines(lines).fold(_.foreach(t => println(t.getMessage)), println)
For input string: "13a"
For input string: "foo"

这很好,但是假设列表很长,并且我决定要捕获有关错误上下文的更多信息,以便更轻松地进行清理。为简单起见,我将在此处仅使用(零索引)行号来表示位置,但上下文也可以包含文件名或其他信息。

绕过位置

一种简单的方法是将位置传递给我的行解析器:

type Position = Int

case class InvalidLine(pos: Position, message: String) extends Throwable(
  f"At $pos%d: $message%s"
)

def parseLine(line: String, pos: Position) = line.parseInt.leftMap(
  _ => InvalidLine(pos, f"$line%s is not an integer!")
)

def parseLines(lines: List[String]) = lines.zipWithIndex.traverseU(
  (parseLine _).tupled andThen (_.toValidationNel)
)

这也有效:

scala> parseLines(lines).fold(_.foreach(t => println(t.getMessage)), println)
At 2: 13a is not an integer!
At 4: foo is not an integer!

但在更复杂的情况下,像这样传递位置会令人不快。

包装错误

另一种选择是包装行解析器产生的错误:

case class InvalidLine(pos: Position, underlying: Throwable) extends Throwable(
  f"At $pos%d: ${underlying.getMessage}%s",
  underlying
)

def parseLines(lines: List[String]) = lines.zipWithIndex.traverseU {
  case (line, pos) => line.parseInt.leftMap(InvalidLine(pos, _)).toValidationNel
}

再一次,它工作得很好:

scala> parseLines(lines).fold(_.foreach(t => println(t.getMessage)), println)
At 2: For input string: "13a"
At 4: For input string: "foo"

但有时我有一个很好的错误 ADT,这种包装感觉不是特别优雅。

返回“部分”错误

第三种方法是让我的行解析器返回一个需要与一些附加信息(在本例中为位置)结合的部分错误。我将在这里使用Reader,但我们也可以将故障类型表示为Position => Throwable。我们可以重复使用上面的第一个(非包装)InvalidLine

def parseLine(line: String) = line.parseInt.leftMap(
  error => Reader(InvalidLine((_: Position), error.getMessage))
)

def parseLines(lines: List[String]) = lines.zipWithIndex.traverseU {
  case (line, pos) => parseLine(line).leftMap(_.run(pos)).toValidationNel
}

这再次产生了所需的输出,但也感觉有点冗长和笨拙。

问题

我一直都遇到这种问题——我正在解析一些杂乱的数据,并希望得到有用的错误消息,但我也不想在我的所有解析逻辑中串接一堆位置信息。

是否有理由更喜欢上述方法之一?有更好的方法吗?

【问题讨论】:

  • 我可能误解了你的问题,因为我提供的答案太简单了,你可能要求别的东西。我相信你也考虑过这个选项。请指出我的解决方案在您的案例中存在哪些不足。
  • “一些乱七八糟的数据”——一定是“人文”数据。
  • 我不认为我们垄断了杂乱的数据,但是是的,我们确实受够了。

标签: validation scala parsing error-handling scalaz


【解决方案1】:

我将您的第一个和第二个选项与本地请求的无堆栈异常结合起来用于控制流。这是我发现的最好的东西,可以让错误处理既完全防弹又不碍事。基本形式如下:

Ok.or[InvalidLine]{ bad =>
  if (somethingWentWrong) bad(InvalidLine(x))
  else y.parse(bad)  // Parsers should know about sending back info!
}

其中bad 在调用时抛出异常,返回传递给它的数据,并且输出是自定义的Either-like 类型。如果从外部作用域注入额外的上下文变得很重要,那么添加额外的转换器步骤就是添加上下文所需要的:

Ok.or[Invalid].explain(i: InvalidLine => Invalid(i, myFile)) { bad =>
  // Parsing logic
}

实际上创建类来完成这项工作比我想在这里发布的要复杂一些(特别是因为在我所有的实际工作代码中都有其他考虑因素会掩盖细节),但这是逻辑。

哦,因为这最终只是一个类的应用方法,你总是可以

val validate = Ok.or[Invalid].explain(/* blah */)

validate { bad => parseA }
validate { bad => parseB }

以及所有常见的技巧。

(我想bad 的类型签名是bad: InvalidLine => Nothingapply 的类型签名是(InvalidLine => Nothing) => T,这不是很明显。)

【讨论】:

    【解决方案2】:

    一个过于简单的解决方案可能是:

    import scala.util.{Try, Success, Failure}
    
    def parseLines(lines: List[String]): List[Try[Int]] =
      lines map { l => Try (l.toInt) }
    
    val lines = List("12", "13", "13a", "14", "foo")
    println("LINES: " + lines)
    
    val parsedLines = parseLines(lines)
    println("PARSED: " + parsedLines)
    
    val anyFailed: Boolean = parsedLines.exists(_.isFailure)
    println("FAILURES EXIST?: " + anyFailed)
    
    val failures: List[Throwable] = parsedLines.filter(_.isFailure).map{ case Failure(e) => e }
    println("FAILURES: " + failures)
    
    val parsedWithIndex = parsedLines.zipWithIndex
    println("PARSED LINES WITH INDEX: " + parsedWithIndex)
    
    val failuresWithIndex = parsedWithIndex.filter{ case (v, i) => v.isFailure }
    println("FAILURES WITH INDEX: " + failuresWithIndex)
    

    打印:

    LINES: List(12, 13, 13a, 14, foo)
    
    PARSED: List(Success(12), Success(13), Failure(java.lang.NumberFormatException: For input string: "13a"), Success(14), Failure(java.lang.NumberFormatException: For input string: "foo"))
    
    FAILURES EXIST?: true
    
    FAILURES: List(java.lang.NumberFormatException: For input string: "13a", java.lang.NumberFormatException: For input string: "foo")
    
    PARSED LINES WITH INDEX: List((Success(12),0), (Success(13),1), (Failure(java.lang.NumberFormatException: For input string: "13a"),2), (Success(14),3), (Failure(java.lang.NumberFormatException: For input string: "foo"),4))
    
    FAILURES WITH INDEX: List((Failure(java.lang.NumberFormatException: For input string: "13a"),2), (Failure(java.lang.NumberFormatException: For input string: "foo"),4))
    

    鉴于您可以将所有这些包装在一个辅助类中,抽象解析函数,概括输入和输出类型,甚至定义错误类型,无论是异常还是其他。

    我建议的是一种简单的基于地图的方法,可以根据任务定义确切的类型。

    烦人的是,您必须保留对parsedWithIndex 的引用才能获取索引和异常,除非您的异常包含索引和其他上下文信息。

    实现示例:

    case class Transformer[From, To](input: List[From], f: From => To) {
      import scala.util.{Try, Success, Failure}
    
      lazy val transformedWithIndex: List[(Try[To], Int)] =
        input map { l => Try ( f(l) ) } zipWithIndex
    
      def failuresWithIndex =
        transformedWithIndex.filter { case (v, i) => v.isFailure }
    
      lazy val failuresExist: Boolean =
        ! failuresWithIndex.isEmpty
    
      def successfulOnly: List[To] =
        for {
          (e, _) <- transformedWithIndex
          value <- e.toOption
        } yield value
    }
    
    val lines = List("12", "13", "13a", "14", "foo")
    
    val res = Transformer(lines, (l: String) => l.toInt)
    
    println("FAILURES EXIST?: " + res.failuresExist)
    println("PARSED LINES WITH INDEX: " + res.transformedWithIndex)
    println("SUCCESSFUL ONLY: " + res.successfulOnly)
    

    打印:

    FAILURES EXIST?: true
    
    PARSED LINES WITH INDEX: List((Success(12),0), (Success(13),1), (Failure(java.lang.NumberFormatException: For input string: "13a"),2), (Success(14),3), (Failure(java.lang.NumberFormatException: For input string: "foo"),4))
    
    SUCCESSFUL ONLY: List(12, 13, 14)
    

    Try 可以替换为Either 或您自己的自定义Failure

    这确实感觉有点面向对象而不是功能。

    【讨论】:

    • 感谢您的回答,但是是的,这与 Scalaz 提供的出色功能抽象相去甚远——即使是 isFailure 也让我有点紧张。我会尽快回复更详细的。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-04-04
    • 1970-01-01
    相关资源
    最近更新 更多