validation - 验证错误中的位置信息

Question

问题

我将从一个简化的解析问题开始。假设我有一个字符串列表，我想将其解析为一个整数列表，并且我想累积错误。这在 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
}

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

问题

我一直遇到这种问题——我正在解析一些困惑的数据并想要有用的错误消息，但我也不想在我的所有解析逻辑中穿插一堆位置信息。

是否有理由偏爱上述方法之一？有更好的方法吗？

Answer 1

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

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

where bad 在被调用时抛出一个异常，返回传递给它的数据，输出是一个自定义的 Either 类型。如果从外部范围注入(inject)额外的上下文变得很重要，添加额外的转换器步骤就是添加上下文所需的全部:

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 => Nothing，而 apply 的类型签名code> 是 (InvalidLine => Nothing) => T。)