第六个问题异常类型层级Duan 是否需要预定义一套异常类型层级还是直接用 Python 内置的Plain Text# 选项 A直接使用 Python 内置 中文别名映射 # 无需定义编译器内置映射表 值错误 → ValueError 类型错误 → TypeError 键错误 → KeyError 索引错误 → IndexError ... # 选项 B自定义异常类型可继承 类 值错误(异常) 段落 __init__ 接收 己, 消息 父.__init__(己, 消息) 结束。 结束。 # 选项 C混合选项 A 选项 B 可扩展 # 内置中文别名但允许用户自定义新的异常类型推荐选项 A编译器内置映射表足够实用简洁且自举友好。自定义异常类型可以放到 Level 6类型注解完善后再支持。你倾向哪个选项 A 。我有个疑问就是选A对后面用llvm编译的时候会有什么影响吗用户问了一个非常好的问题使用 Python 内置异常类型映射对 LLVM 后端编译有什么影响这是一个关键的架构问题我需要仔细分析当前 Duan 编译器的多后端架构Python 后端自举编译器生成 Python 代码LLVM 后端生成 C/LLVM IR编译成本地 EXEPython 后端的异常处理直接使用 Python 的 try/except/finally内置异常映射值错误 → ValueError直接生成 Python 代码非常简单LLVM 后端的异常处理需要生成 C 代码中的异常处理C 的异常处理通常使用 setjmp/longjmp 或者 C 的 try/catch需要对异常类型做不同的处理具体影响C 代码的异常处理方式可以使用 libunwind / C exception 机制或者使用类似 setjmp/longjmp 的方式当前实现需要把 Python 的 try/except 转换为 C 的结构异常类型匹配C 端需要知道有哪些异常类型可以使用枚举或字符串比较或者构建一个异常对象系统当前项目已有的 LLVM 异常处理基础从 src/llvm/ 目录下的文件来看已经有一些异常处理的实现。从 test_llvm_exception 相关测试来看LLVM 后端已经支持某种形式的异常处理。我需要向用户解释选项 A 对 LLVM 后端确实有影响但可以通过设计来解决。具体方案是保持前端词法/语法/解析一致代码生成时为 LLVM 后端生成特定的异常处理代码而异常类型映射可以在代码生成阶段处理不影响前端的统一性。这是个好问题。会有影响但可以设计成兼容的。架构分析当前 Duan 有多个后端Python 后端自举编译器生成 Python 代码 → 直接用try/exceptLLVM 后端生成 C 代码 → 需要用 C 的异常机制setjmp/longjmp或 Ctry/catch关键洞察异常类型映射属于代码生成阶段不影响前端源码尝试 ... 捕获 值错误... ↓ ┌────┴────┐ ↓ ↓ Python 后端 LLVM 后端 ValueError 自定义异常类型系统 try/except setjmp/longjmp具体方案词法/语法/解析层统一处理尝试/捕获/最终/抛出生成抽象的 AST/IR代码生成层根据后端生成不同的异常处理代码Python直接生成try/exceptLLVM生成适配 C 异常机制的代码已有基础从项目中的test_llvm_exception、src/llvm/codegen.py来看LLVM 后端已经有某种形式的异常处理实现。结论选项 A 不阻碍 LLVM 后端只需要在 LLVM 代码生成器里实现一套对应的异常处理逻辑。我会在设计方案里明确这一点。继续下一个问题第七个问题异常对象的表达在抛出和捕获中异常对象如何表示# 抛出 抛出 出错了 抛出 错误码 # 变量 → 自动包装为异常 # 捕获 捕获 值错误 as e # e 是异常对象 输出(e) # 输出异常信息as e是可选的如果不需要异常对象可以省略抛出时表达式为字符串→ 自动包装成Exception(字符串)抛出时表达式为对象→ 直接抛出这个设计 OK 吗
Duan 是否需要预定义一套异常类型层级？还是直接用 Python 内置的？
第六个问题异常类型层级Duan 是否需要预定义一套异常类型层级还是直接用 Python 内置的Plain Text# 选项 A直接使用 Python 内置 中文别名映射 # 无需定义编译器内置映射表 值错误 → ValueError 类型错误 → TypeError 键错误 → KeyError 索引错误 → IndexError ... # 选项 B自定义异常类型可继承 类 值错误(异常) 段落 __init__ 接收 己, 消息 父.__init__(己, 消息) 结束。 结束。 # 选项 C混合选项 A 选项 B 可扩展 # 内置中文别名但允许用户自定义新的异常类型推荐选项 A编译器内置映射表足够实用简洁且自举友好。自定义异常类型可以放到 Level 6类型注解完善后再支持。你倾向哪个选项 A 。我有个疑问就是选A对后面用llvm编译的时候会有什么影响吗用户问了一个非常好的问题使用 Python 内置异常类型映射对 LLVM 后端编译有什么影响这是一个关键的架构问题我需要仔细分析当前 Duan 编译器的多后端架构Python 后端自举编译器生成 Python 代码LLVM 后端生成 C/LLVM IR编译成本地 EXEPython 后端的异常处理直接使用 Python 的 try/except/finally内置异常映射值错误 → ValueError直接生成 Python 代码非常简单LLVM 后端的异常处理需要生成 C 代码中的异常处理C 的异常处理通常使用 setjmp/longjmp 或者 C 的 try/catch需要对异常类型做不同的处理具体影响C 代码的异常处理方式可以使用 libunwind / C exception 机制或者使用类似 setjmp/longjmp 的方式当前实现需要把 Python 的 try/except 转换为 C 的结构异常类型匹配C 端需要知道有哪些异常类型可以使用枚举或字符串比较或者构建一个异常对象系统当前项目已有的 LLVM 异常处理基础从 src/llvm/ 目录下的文件来看已经有一些异常处理的实现。从 test_llvm_exception 相关测试来看LLVM 后端已经支持某种形式的异常处理。我需要向用户解释选项 A 对 LLVM 后端确实有影响但可以通过设计来解决。具体方案是保持前端词法/语法/解析一致代码生成时为 LLVM 后端生成特定的异常处理代码而异常类型映射可以在代码生成阶段处理不影响前端的统一性。这是个好问题。会有影响但可以设计成兼容的。架构分析当前 Duan 有多个后端Python 后端自举编译器生成 Python 代码 → 直接用try/exceptLLVM 后端生成 C 代码 → 需要用 C 的异常机制setjmp/longjmp或 Ctry/catch关键洞察异常类型映射属于代码生成阶段不影响前端源码尝试 ... 捕获 值错误... ↓ ┌────┴────┐ ↓ ↓ Python 后端 LLVM 后端 ValueError 自定义异常类型系统 try/except setjmp/longjmp具体方案词法/语法/解析层统一处理尝试/捕获/最终/抛出生成抽象的 AST/IR代码生成层根据后端生成不同的异常处理代码Python直接生成try/exceptLLVM生成适配 C 异常机制的代码已有基础从项目中的test_llvm_exception、src/llvm/codegen.py来看LLVM 后端已经有某种形式的异常处理实现。结论选项 A 不阻碍 LLVM 后端只需要在 LLVM 代码生成器里实现一套对应的异常处理逻辑。我会在设计方案里明确这一点。继续下一个问题第七个问题异常对象的表达在抛出和捕获中异常对象如何表示# 抛出 抛出 出错了 抛出 错误码 # 变量 → 自动包装为异常 # 捕获 捕获 值错误 as e # e 是异常对象 输出(e) # 输出异常信息as e是可选的如果不需要异常对象可以省略抛出时表达式为字符串→ 自动包装成Exception(字符串)抛出时表达式为对象→ 直接抛出这个设计 OK 吗
