Pine语言自定义rising_函数运行报错排查求助

核心报错根因 #

所有报错并非函数本身逻辑失效——该函数此前在其他场景稳定运行，说明逻辑本身没有问题，不存在本月突然损坏的情况。触发连锁报错的核心原因是当前指标代码中调用该函数时的入参类型、顺序和函数定义的预期不匹配，触发了Pine的静态类型推导连锁反应。

报错对应问题定位 #

逐行匹配函数代码和报错信息，可以精准定位错误触发点：

• 第一处报错（>运算符入参类型不匹配，参数为series[bool]和整型字面量）：对应函数内部的length > 0判断行。正常情况下length是数值类型的回看长度，能和整数0做大小比较；现在Pine识别到length是布尔序列，说明调用函数时把两个入参的位置传反了：本该放在第一位的数值序列values没传对，把一个布尔序列误传到了第二个参数length的位置，导致类型完全错位。
• 第二处报错（<运算符入参类型不匹配，参数为series[bool]和整数序列）：对应函数内部的length < bar_index判断行。这是传参错位的连锁结果：因为length变量被错误识别为布尔序列，拿布尔值和整数序列bar_index做大小比较，自然触发类型不匹配。
• 第三处报错（for循环索引不能用字符串类型值）：同样是传参错位的连锁反应：Pine对错误类型的length做推导时，把非整数类型的length识别为字符串类的非法循环边界，导致循环参数校验失败抛出提示。

落地修复方案 #

• 逐行核对所有调用rising_()的位置，严格匹配函数定义的参数顺序：第一个位置传入需要判断的数值序列（如收盘价、自定义计算的指标值），第二个位置传入正整数类型的回看长度。例如正确调用写法为rising_(close, 10)，严禁调换两个参数的顺序，也不能在第一个参数位置传入布尔类型序列。
• 检查上游传入的length变量赋值逻辑，避免把布尔判断结果误赋值给长度变量（如出现length = close > open这类错误写法），确保传入的长度值始终为整数类型。
• 给自定义函数的入参加上显式类型标注，从根源避免类型推导的连锁模糊报错。优化后的函数代码：

rising_(series<float> values, int length) =>
    current_ = values[0]
    ok_ = false
    if length > 0 and bar_index >= length
        ok_ := true
        for i = 1 to length
            if not na(values[i]) and current_ <= values[i]
                ok_ := false
                break
    ok_

加了类型标注后，Pine会在传参类型错误时直接精准提示“第X个参数预期为XX类型，实际传入XX类型”，不会把错误传导到函数内部的比较、循环逻辑中。

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