问题描述
我有一个HaxeFlixel项目,在杂项目标(包括flash,neko和Windows)的Debug模式下运行正常.但是在发布模式中定位 Windows 时,我遇到了意外崩溃,并且令人惊讶的是,它发生在try-catch块中.这是崩溃功能:
I have a HaxeFlixel project, that is working OK in Debug mode for misc targets, including flash, neko and windows. But Targeting Windows in Release mode, I'm having an unexpected crash, and surprisingly it's happening inside a try-catch block. Here's the crashing function:
/**
* Will safely scan a parent node's children, search for a child by name, and return it's text.
* @param parent an Fast object that is parent of the `nodeNamed` node
* @param nodeName the node's name or a comma-separated path to the child (will scan recursively)
* @return node's text as String, or null if child is not there
*/
public static function getNodeText(parent:Fast, nodeName:String):String {
try {
var _node : Fast = getNodeNamed(parent, nodeName);
//if (_node == null)
// return null;
// next line will crash if _node is null
var it :Iterator<Xml> = _node.x.iterator();
if ( it == null || !it.hasNext() )
return null;
var v = it.next();
var n = it.next();
if( n != null ) {
if( v.nodeType == Xml.PCData && n.nodeType == Xml.CData && StringTools.trim(v.nodeValue) == "" ) {
var n2 = it.next();
if( n2 == null || (n2.nodeType == Xml.PCData && StringTools.trim(n2.nodeValue) == "" && it.next() == null) )
return n.nodeValue;
}
//does not only have data (has children)
return null;
}
if( v.nodeType != Xml.PCData && v.nodeType != Xml.CData )
//does not have data";
return null;
return v.nodeValue;
}catch (err:Dynamic) {
trace("Failed parsing node Text [" + nodeName+"] " + err );
return null;
}
}
通过启用if (_node == null) return null;
行,它可以再次安全运行.通过将错误捕获为Dynamic
,我认为应该捕获所有可能的错误类型!为什么会这样呢?为何它会出现在发布模式下?
By enabling if (_node == null) return null;
line, It's working safely again. By catching errors as Dynamic
I thought I was supposed to catch every possible error type! Why is this happening? And why is it appearing in release mode?
我的IDE是FlashDevelop,如果有什么区别,我正在使用HaxeFlixel 3.3.6,lime 0.9.7和openFL 1.4.0
My IDE is FlashDevelop, and I'm using HaxeFlixel 3.3.6, lime 0.9.7 and openFL 1.4.0, if that makes any difference
我怀疑这与转换后的C ++代码错过Dynamic
异常的方式有关.等效的生成的C ++代码为:
I suspect this has to do with how the translated C++ code missed the Dynamic
Exception. The equivalent generated C++ code is:
STATIC_HX_DEFINE_DYNAMIC_FUNC2(BaxXML_obj,_getNodeNamed,return )
::String BaxXML_obj::getNodeText( ::haxe::xml::Fast parent,::String nodeName){
HX_STACK_FRAME("bax.utils.BaxXML","getNodeText",0x4a152f07,"bax.utils.BaxXML.getNodeText","bax/utils/BaxXML.hx",56,0xf6e2d3cc)
HX_STACK_ARG(parent,"parent")
HX_STACK_ARG(nodeName,"nodeName")
HX_STACK_LINE(56)
try
{
HX_STACK_CATCHABLE(Dynamic, 0);
{
HX_STACK_LINE(57)
::haxe::xml::Fast _node = ::bax::utils::BaxXML_obj::getNodeNamed(parent,nodeName); HX_STACK_VAR(_node,"_node");
HX_STACK_LINE(63)
Dynamic it = _node->x->iterator(); HX_STACK_VAR(it,"it");
// ... Let's skip the irrelevant code
}
catch(Dynamic __e){
{
HX_STACK_BEGIN_CATCH
Dynamic err = __e;{
HX_STACK_LINE(82)
::String _g5 = ::Std_obj::string(err); HX_STACK_VAR(_g5,"_g5");
HX_STACK_LINE(82)
::String _g6 = (((HX_CSTRING("Failed parsing node Text [") + nodeName) + HX_CSTRING("] ")) + _g5); HX_STACK_VAR(_g6,"_g6");
HX_STACK_LINE(82)
::haxe::Log_obj::trace(_g6,hx::SourceInfo(HX_CSTRING("BaxXML.hx"),82,HX_CSTRING("bax.utils.BaxXML"),HX_CSTRING("getNodeText")));
HX_STACK_LINE(83)
return null();
}
}
}
HX_STACK_LINE(56)
return null();
}
推荐答案
您定义了哪些haxedef?
What haxedefs do you have defined?
将这些添加到您的project.xml中可能会有所帮助:
Adding these to your project.xml might help:
<haxedef name="HXCPP_CHECK_POINTER"/> <!--makes null references cause errors-->
<haxedef name="HXCPP_STACK_LINE" /> <!--if you want line numbers-->
<haxedef name="HXCPP_STACK_TRACE"/> <!--if you want stack traces-->
您还可以尝试crashdumper库: https://github.com/larsiusprime/crashdumper
You might also try the crashdumper library:https://github.com/larsiusprime/crashdumper
(Crashdumper默认将HXCPP_CHECK_POINTER作为其include.xml的一部分打开,并将为hxcpp的错误和openfl/lime的未捕获的错误事件设置钩子)
(Crashdumper will turn on HXCPP_CHECK_POINTER by default as part of it's include.xml, and will set up hooks for both hxcpp's errors and openfl/lime's uncaught error events)
这篇关于当对C ++目标使用Release模式时,为什么这个Haxe try-catch块仍然崩溃的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!