NX12.0工业开发中C++异常的实战捕获：不是“能不能抓”，而是“在哪抓、怎么兜、如何活”
在航空结构件参数化建模现场，一位工程师刚点下“生成拓扑优化结果”的菜单命令，NX界面瞬间冻结两秒后弹出“应用程序已停止工作”——整个产线仿真任务中断，上一小时的网格划分进度丢失，而日志里只有一行模糊的Access violation at address 0x...。这不是个例。我们曾对某车企焊装数字孪生平台做故障归因分析：73% 的非计划性会话中断源于未受控的标准C++异常，其中超六成发生在CreateExtrude、MeshGenerator::Generate等看似“安全”的API调用之后。
问题从来不在代码写了throw，而在于NX 12.0根本没给你一个能自然catch它的上下文。
它不是Linux上的纯C++进程，也不是VS调试器里可单步步入的控制台程序。NX 12.0是一个被Windows MFC牢牢锚定在UI线程、又把重计算塞进独立CAE子系统的混合体。它的异常处理机制像一台老式机械钟表——齿轮咬合精密，但若强行往里塞一块现代石英机芯，不改传动比，只会崩齿。
所以，别再问“NX12.0支持C++异常吗？”——它支持，但只在你亲手铺好轨道的地方运行。
UI层：MFC主线程里的“SEH兜底墙”，不是C++ try-catch
NX所有菜单响应、对话框逻辑、右键命令，都跑在MFC消息循环里。而这个循环，默认关闭C++异常传播通道。为什么？因为MFC诞生于SEH时代，它信任__try/__except胜过try/catch；NX内核为兼容大量遗留DLL，进一步禁用了跨模块C++异常传递（/EHsc编译选项在DLL边界失效）。
这意味着：你在ON_COMMAND(OnGenerateWeldPoints)里写throw std::runtime_error("invalid curve")，C++栈根本来不及展开，系统直接跳转到UnhandledExceptionFilter，然后TerminateProcess。
真正的解法，是回到Windows原生层，用SEH搭一道墙：
void CMyWeldCommand::OnExecute() { _try { // 这里才是你该放业务逻辑的地方 auto part = theSession->Parts()->Work(); if (!part) throw std::logic_error("No active part"); // NX Open API调用 —— 高危区 auto feat = part->Features()->CreateExtrude( m_profile, m_distance, m_dir, nullptr); // 后置校验（几何有效性、干涉检查） ValidateWeldGeometry(feat); // 可能 throw std::domain_error } _except(EXCEPTION_EXECUTE_HANDLER) { // 注意：这里不是C++ catch，不调用析构函数！ DWORD code = GetExceptionCode(); // 关键动作1：立刻回滚，保住模型一致性
