NX 12.0 C++ 异常处理实战手记：一个模具厂工程师的踩坑与破局之路
去年冬天，我在某德系汽车模具厂驻场支持时，遇到一个反复出现的“幽灵问题”：用户点击一个自定义的“自动分模面生成”命令后，NX 突然弹出那个熟悉的红色对话框——“An exception has occurred…”，接着模型树卡死、临时体残留、许可证锁住，重启软件成了唯一选择。日志里只有一行干巴巴的std::out_of_range，没有文件名，没有行号，甚至不确定是我们的插件抛的，还是 NX 内部调用 JT 解析器时崩的。
这不是语法错误，也不是逻辑漏洞——这是C++ 异常在工业软件躯体里穿行时，被 ABI 边界生生截断的痛感。
后来我们花了三周时间，把整个异常链从throw到catch、从堆栈到符号、从 CRT 链接到线程上下文，一层层剥开。今天不讲教科书定义，也不列 SDK 文档原文，只说我们在产线上真实验证过的、能立刻见效的几件事。
插件入口那堵“墙”，你建对了吗？
NX 主程序（ugii.exe）确实有全局异常捕获机制，但它不是你的保险柜，而是最后一道急救室门。一旦异常穿过 DLL 边界，它看到的很可能不是一个std::runtime_error对象，而是一块内存乱码——因为你的插件用 v142 编译，而 NX 是 v140；或者你用了/MT静态链接 CRT，结果new在插件堆上，delete却被 NX 主程序在自己的堆上调用。
所以第一件事，也是最简单却最容易被跳过的一件事：在每一个ufusr_*或extern "C" DllExport函数入口，亲手砌一堵try/catch墙。
extern "C" DllExport void ufusr_ask_for_built_in_functions(...) { try { // ✅ 所有业务代码必须在这里面 run_mold_surface_generator(); } catch (const std::exception& e) { // 这里是你和用户之间最后的沟通窗口 UF_UI_open_listing_window(); UF_UI_write_listing_window("❌ CRITICAL ERROR (Plugin Level)\n"); UF_UI_write_listing_window("Message: "); UF_UI_write_listing_window(e.what()); UF_UI_write_listing_window("\nTime: "); char time_buf[64]; _strdate_s(time_buf, sizeof(time_buf)); UF_UI_write_listing_window(time_buf); // ⚠️ 关键动作：主动清理，而不是等析构 UF_MODL_delete_temporary_objects(); // 清空临时体 UF_O
（springcloud微服务课day6）)
