问调用Transfer()时，Opencascade崩溃

EN

看起来评论已经给出了问题的答案，或者更准确地说是答案。

• STEPCAFControl_Reader::ReadFile()返回读取状态，应该在调用STEPCAFControl_Reader::Transfer().之前检查该状态。
• 通常，将OCCT算法应用于尝试/捕获块并检查OCCT异常(Standard_Failure)是一种很好的做法。
• 在try语句开头添加OCC_CATCH_SIGNALS (仅在Linux上需要)和在工作线程创建中添加OSD::SetSignal(false)，以便将异常情况(访问冲突、空引用等)重定向到C++异常(OSD_Signal是Standard_Failure的子类)。这可能会与混合环境中的其他信号处理程序发生冲突--因此也请检查应用程序使用的其他框架的文档。
• 如果在调用带有有效参数的OCCT算法时捕捉到诸如NULL取消引用之类的失败--这是OCCT中的一个bug，它是希望以某种方式修复的，即使输入步骤文件包含触发此类问题的语法/逻辑错误。在OCCT Bugtracker上报告问题，提供足够的信息来复制bug，包括示例文件--这对开发人员仅仅说OCCT在某个地方崩溃是没有帮助的。还可以考虑通过调试OCCT代码和建议修补程序来为这个开源项目做出贡献。
• 检查步骤文件读取日志，以查看文件本身中可能出现的错误。考虑向生成损坏文件的系统报告问题，即使主文件内容可以由分步读取器加载。

在基于OSD::SetSignal()的应用程序(如CAD )中使用OCCT来提高其对应用程序/OCCT代码中非致命错误的鲁棒性是一种常见的做法。它更方便用户报告内部错误消息，而不是默默地崩溃。

但是需要注意的是，OSD::SetSignal()不能保证应用程序不会崩溃，也不能保证应用程序在捕捉到这样的故障后能够正常工作--由于某些信号的异步性质，内存在C++异常被引发时可能已经损坏，从而导致各种不想要的行为。由于这个原因，最好不要忽略这种异常，即使它看起来像应用程序可以很好地处理它们。

  OSD::SetSignal(false); // should be called ones at application startup
  STEPCAFControl_Reader aReader;
  try
  {
    OCC_CATCH_SIGNALS // necessary for redirecting signals on Linux
    if (aReader.ReadFile (theFilePath) != IFSelect_RetDone) { return false; }
    if (!aReader.Transfer (myXdeDoc)) { return false; }
  }
  catch (Standard_Failure const& theFailure)
  {
    std::cerr << "STEP import failed: " << theFailure.GetMessageString() << "\n";
    return false;
  }
  return true;