先明确你提供的测试代码：

自定义类型包代码 #

CREATE OR REPLACE PACKAGE MY_TYPES IS 
    PRAGMA SERIALLY_REUSABLE; 
    SUBTYPE my_number IS NUMBER(3,0); 
END MY_TYPES; 
/

测试存储过程代码 #

DECLARE 
    PROCEDURE print(my_number_i IN my_types.my_number) IS 
    BEGIN 
        dbms_output.put_line(my_number_i); 
    END; 
BEGIN 
    print(my_number_i => 35); 
END; 
/

问题现象 #

在PL/SQL Developer中执行上述代码时，抛出ORA-06502: PL/SQL: numeric or value error: number precision too large错误；但将参数值改为非35的数值（比如34、36）时，过程可正常完成。而在SQL Developer和SQL*Plus中执行该代码均正常，仅PL/SQL Developer存在此问题。

结合这个特殊场景，我整理了几个可能的原因：

1. PL/SQL Developer客户端侧的类型预校验bug #

PL/SQL Developer在执行代码前，会在客户端对输入字面量做额外的类型匹配校验，而非完全依赖Oracle服务器端的转换逻辑。NUMBER(3,0)的取值范围是-999到999，35显然在范围内，但PL/SQL Developer的校验逻辑可能存在特定数值的bug——对35这个字面量解析时，错误判定其精度超出范围，其他数值则能正常通过校验。

2. 版本兼容性问题 #

不同版本的PL/SQL Developer对Oracle自定义子类型的处理存在差异。部分旧版本在处理字面量绑定到自定义子类型时，存在逻辑漏洞，刚好35这个数值触发了该漏洞。建议检查你的PL/SQL Developer版本，尝试升级到最新稳定版后再测试。

3. 参数绑定模式差异 #

PL/SQL Developer的参数绑定方式和SQL Developer、SQL*Plus不同。比如处理35这个字面量时，它可能以某种特定数值类型（如INTEGER）传递，而非自动转换为符合my_types.my_number的类型，导致服务器端接收到的参数类型不匹配，触发精度错误。其他数值可能因转换逻辑的特殊性，未触发该问题。

4. 客户端严格校验设置影响 #

检查PL/SQL Developer的设置，是否开启了严格类型检查相关选项。某些高级设置会强制客户端对输入参数做更严苛的校验，而该校验逻辑存在bug，导致35被误判。可以尝试重置PL/SQL Developer的默认设置，或关闭相关严格校验选项后重试。

验证方法 #

你可以尝试绕过客户端字面量校验，先将35赋值给my_types.my_number类型的变量，再传递给存储过程：

DECLARE 
    PROCEDURE print(my_number_i IN my_types.my_number) IS 
    BEGIN 
        dbms_output.put_line(my_number_i); 
    END; 
    v_num my_types.my_number := 35;
BEGIN 
    print(my_number_i => v_num); 
END; 
/

如果这样执行正常，就说明问题确实出在PL/SQL Developer对字面量的客户端校验逻辑上。

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