Ruby封装FFI外部库时如何捕获yield中的break？

次要问题：break时的底层栈变化 #

当你在each_shape的block里调用break时，Ruby会触发LocalJumpError（Ruby内部用于控制流的异常），栈的变化过程如下：

• 首先跳出当前的yield代码块
• 接着跳出FFI回调的lambda
• 异常向上传递，直接中断Ruby层面的each_shape方法执行，但C库的cpSpaceEachShape函数仍会继续同步执行——因为Ruby的控制流异常无法跨越到C栈，C函数不会感知到Ruby的break操作，会继续调用剩余的回调，只是Ruby不再处理这些回调
• 最终导致C库内部状态因迭代未正常完成而不一致，后续调用cpSpaceStep就会报错

主要问题：捕获顶层block的break #

你之前的尝试无效，是因为break触发的是LocalJumpError而非StopIteration，且未正确在回调内部处理该异常。以下是两种可行方案：

方案1：在回调中捕获break，标记取消状态 #

通过捕获LocalJumpError并识别break信号，标记迭代取消，让后续回调跳过yield逻辑，确保C函数能完整执行完所有回调，维持C库状态一致：

def each_shape(&block)
  cancelled = false
  callback = lambda do |*args|
    return if cancelled

    begin
      yield(*args) # 传递C回调的参数给用户block
    rescue LocalJumpError => e
      # 仅处理break的情况，next/redo等其他控制流重新抛出
      if e.reason == :break
        cancelled = true
      else
        raise e
      end
    end
  end

  cpSpaceEachShape(callback)
end

这个方案允许用户使用标准Rubybreak语法，同时保证C库完成迭代流程，避免状态异常。

方案2：预缓存所有结果到Ruby数组 #

如果C库的回调数据量不大，此方案更简单可靠：先一次性将所有shape缓存到Ruby数组，再对数组进行迭代。用户的break操作只会影响Ruby层面的数组迭代，完全不会干扰C库状态：

def each_shape(&block)
  shapes = []
  callback = lambda do |*args|
    shapes << args.first # 假设回调第一个参数是shape对象，根据实际调整
  end
  # 先完整执行C库的迭代，缓存所有结果
  cpSpaceEachShape(callback)
  # 再用Ruby原生数组迭代器处理用户block
  shapes.each(&block)
end

此方案的缺点是会占用额外内存存储所有shape，但胜在实现简单，完全符合Ruby迭代习惯，无兼容性问题。

内容的提问来源于stack exchange，提问作者Daniel Rikowski