Skip to content

Latest commit

 

History

History
68 lines (49 loc) · 2.95 KB

pattern-debugging-pipelines-breakpoint.adoc

File metadata and controls

68 lines (49 loc) · 2.95 KB

使用调试器调试管道

目的

  • 强制管道在特定场景或条件下进入调试器。

参考
另请参阅
代码和解释

你可以在管道内的任何操作符的任何闭包内设置一个断点，触发调试器激活以检查数据。 由于 map 操作符经常用于简单的输出类型转换，因此它通常是具有你可以使用的闭包的优秀候选者。 如果你想查看控制消息，那么为 handleEvents 提供的任何闭包添加一个断点，目标实现起来将非常方便。

你还可以使用 breakpoint 操作符触发调试器，这是查看管道中发生情况的一种非常快速和方便的方式。 breakpoint 操作符的行为非常像 handleEvents，使用一些可选参数，期望返回一个布尔值的闭包，如果返回 true 将会调用调试器。

可选的闭包包括：

  • receiveSubscription

  • receiveOutput

  • receiveCompletion

.breakpoint(receiveSubscription: { subscription in
    return false // return true to throw SIGTRAP and invoke the debugger
}, receiveOutput: { value in
    return false // return true to throw SIGTRAP and invoke the debugger
}, receiveCompletion: { completion in
    return false // return true to throw SIGTRAP and invoke the debugger
})

这允许你提供逻辑来评估正在传递的数据，并且仅在满足特定条件时触发断点。 通过非常活跃的管道会处理大量数据，这将是一个非常有效的工具，在需要调试器时，让调试器处于活动状态，并让其他数据继续移动。

如果你只想在错误条件下进入调试器，则便利的操作符 breakPointOnError 是完美的选择。 它不需要参数或闭包，当任何形式的错误条件通过管道时，它都会调用调试器。

.breakpointOnError()
Note

断点操作符触发的断点位置不在你的代码中，因此访问本地堆栈和信息可能有点棘手。 这确实允许你在极其特定的情况下检查全局应用状态（每当闭包返回 true 时，使用你提供的逻辑），但你可能会发现在闭包中使用常规断点更有效。 breakpoint() 和 breakpointOnError() 操作符不会立即将你带到闭包的位置，在那里你可以看到可能触发断点的正在传递的数据、抛出的错误或控制信号。 你通常可以在调试窗口内通过堆栈跟踪以查看发布者。

当你在操作符的闭包中触发断点时，调试器也会立即获取该闭包的上下文，以便你可以查看/检查正在传递的数据。