一、背景C错误处理的痛点文章目录一、背景C错误处理的痛点二、Wrong.h核心设计极简却精妙的双类架构三、核心用法从源头“防火”而非事后“救火”场景1空指针检测场景2数组越界检测四、设计精髓做“平台”不做“业务”五、对比传统方案优势一目了然六、总结C原生异常处理try-catch是典型的“事后救火”——先执行危险操作等异常触发后再捕获补救不仅存在栈展开的性能开销还对空指针解引用、数组[]越界等“未定义行为”束手无策而传统的布尔判断又容易和业务逻辑耦合复杂规则下可读性、复用性极差。有没有一种方式既能从源头“防火”杜绝错误又能兼顾灵活性和低耦合我用50行代码写了一个Wrong.h头文件用极简的设计实现了“预判式错误处理”核心是把“规则定义权”交还给使用者完美适配各类业务场景。二、Wrong.h核心设计极简却精妙的双类架构整个头文件仅包含两个核心类无复杂语法、无冗余逻辑却能覆盖80%的业务级错误处理场景#ifndefWRONG_H#defineWRONG_H#includefunctional#includestring// 1. 泛型规则执行器只负责执行使用者定义的判断规则templatetypenameTclassWatcher{public:Watcher(){}~Watcher(){}// 核心接收检测目标判断Lambda返回执行结果boolcond(Ttar,std::functionbool(T)cd){returncd(tar);}};// 2. 错误信息容器逻辑执行器只负责存错误信息、执行业务逻辑classWrong{protected:std::string err_inf;// 仅存储错误信息无任何处理逻辑public:Wrong(std::string name):err_inf(name){}virtual~Wrong(){}// 对标std::exception降低学习成本std::stringwhat()const{returnerr_inf;}// 仅执行使用者传入的业务逻辑Lambdavoidtodo(std::functionvoid()dn){dn();}};#endif三、核心用法从源头“防火”而非事后“救火”以“空指针检测”和“数组越界检测”两个经典场景为例看Wrong.h的使用方式场景1空指针检测#includeiostream#includeWrong.hintmain(){Watcherint*s;// 适配指针类型Wrongw(空指针错误);// 自定义错误信息w.todo([]()mutable{int*pnullptr;// 使用者自定义判断规则指针非空if(s.cond(p,[](int*pp){returnpp!nullptr;})){std::cout*pstd::endl;// 仅规则满足时执行}else{std::coutw.what()std::endl;// 输出自定义错误}});return0;}场景2数组越界检测#includeiostream#includevector#includeWrong.hstd::vectorintvec{10,20,30};intmain(){Watchersize_ts;// 适配索引类型Wrongw(索引越界);w.todo([]()mutable{size_t num4;// 使用者自定义判断规则索引合法if(s.cond(num,[](size_ttemp){returnnum0numvec.size();})){std::coutvec.at(num)std::endl;}else{std::coutw.what()std::endl;}});return0;}四、设计精髓做“平台”不做“业务”Wrong.h看似简单实则暗藏现代C框架的核心设计哲学单一职责Watcher只做“规则执行器”Wrong只做“信息容器逻辑执行器”两者完全解耦控制权反转框架不封装任何判断规则而是把“什么是错、怎么判断错”的权利交给使用者极简适配模板支持任意类型检测Lambda适配任意复杂规则无需修改框架源码即可扩展用户体验对齐what()方法对标std::exception降低开发者学习成本。五、对比传统方案优势一目了然方案核心问题Wrong.h解决方案try-catch异常被动救火、拦不住未定义行为、性能损耗主动预判、从源头杜绝错误、无额外开销纯布尔判断逻辑耦合、复杂规则可读性差规则与业务解耦、Lambda拆分复杂逻辑传统错误类规则固化、扩展需改源码规则自定义、零成本扩展六、总结Wrong.h用50行代码证明好的工具不一定复杂关键是抓准痛点、释放使用者的灵活性。它不试图封装所有场景而是提供“最基础的执行能力”让开发者根据业务自定义规则——这种“存异”的设计思路正是C在业务场景下的最优解之一。