2013年3月6日
运行时错误处理
正如那些为安卓构建应用的人已经注意到的那样，我们已经改变了报告错误的方式。 首先在安卓上进行此更改是必要的，因为改进的运行时错误处理是实现自定义安卓权限功能的先决条件。
现在是时候让其他平台（iOS 和模拟器）也赶上并实现运行时错误处理了。我们还将推出 **未处理错误监听器**，该监听器可用于捕获否则会触发 **运行时错误** 弹出窗口的错误。它不能修复你的运行时错误，但它可以隐藏它们。
这是一个如何定义运行时错误处理程序的示例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
local function myUnhandledErrorListener( event ) local iHandledTheError = true if iHandledTheError then print( "正在处理未处理的错误", event.errorMessage ) else print( "未处理未处理的错误", event.errorMessage ) end return iHandledTheError end Runtime:addEventListener("unhandledError", myUnhandledErrorListener) |
传递给监听器的 **event** 表具有 **errorMessage** 和 **stackTrace** 参数，它们分别是错误导致的错误消息和错误发生点的堆栈跟踪。从监听器返回 **true** 将抑制弹出警报消息并允许应用程序继续运行。 返回 **false** 将显示弹出窗口并中止应用程序（如果你的代码中没有实现 **unhandledError** 监听器，则这是默认操作），但你将有机会执行诸如将应用程序状态记录到控制台之类的操作。
你将在下一个每日构建中看到的主要更改是发生运行时错误时弹出的消息。 如果你想捕获并抑制弹出消息和应用程序中止，则需要添加上述的 **unhandledError** 监听器。
上述功能应从每日构建版本 1044 及更高版本开始提供。
Andreas
发布于 01:46, 3月7日太棒了！ 这已经帮助了我的一些应用程序的安卓版本，现在 iOS 和模拟器也有这个功能，这非常有帮助。
谢谢！
Stephen Lewis
发布于 08:51, 3月7日关于在已发布的应用程序上运行时，如何处理监听器捕获的错误，有什么提示或最佳实践吗？ 显然，在开发构建中，我想看到错误消息以及我可以获取的所有信息来追踪问题，但是运行我的游戏发布版本的 9 岁儿童不会知道如何处理或关心一些深奥的错误消息。 最有可能的是，我想抑制该消息并防止崩溃。 在仍然提供合理的客户体验的同时，我有什么好方法来获取有关错误的信息？
ojnab
发布于 12:12, 3月7日这太棒了！
@stephen. 你可以使用分析系统记录错误/堆栈跟踪。
JesterXL
发布于 12:19, 3月7日喜欢这个！！！
jufjannie
发布于 15:01, 3月7日默认状态设置为开启是否更合乎逻辑？ 它会阻止弹出窗口，并且你可以在调试模式下将其打开？
现在，当程序员忘记将其放入代码中时，用户可能会收到一个弹出窗口，从而中断应用程序。
如果要更新应用程序，则必须将此代码添加到文件中，这样它就不会开始弹出。
这会增加额外的工作。如果它默认拦截并且不显示弹出窗口，则最终用户和不在乎的程序员没有任何变化。
现在，它被强加在我们身上了。
正如作者在先前关于此的文章中所述。并非所有运行时错误都会导致应用程序崩溃或造成任何不便。现在他们会了。
Simon Fearby
发布于 03:17, 4月11日这可以帮助我检测到堆栈溢出，但不幸的是，没有给我更多信息？
我有在 2013 年 1 月正常工作的代码，但是较新的 Corona 版本破坏了小部件无法输入文本的销毁代码。我将代码回滚到 2013 年 1 月的代码，但是新的 Corona 会崩溃
也许我需要回滚到旧版本的 Corona？
——–
处理未处理的错误 ?:0: 堆栈溢出
2013-04-11 20:06:25.342 Corona Simulator[1339:707] 运行时错误
?:0: 堆栈溢出
堆栈回溯
[C]: in function ‘_cachedRemoveSelf’
?: in function ‘_cachedRemoveSelf’
?: in function ‘_cachedRemoveSelf’
?: in function ‘_cachedRemoveSelf’
?: in function ‘_cachedRemoveSelf’
?: in function ‘_cachedRemoveSelf’
?: in function ‘_cachedRemoveSelf’
?: in function ‘_cachedRemoveSelf’
?: in function ‘_cachedRemoveSelf’
?: in function ‘_cachedRemoveSelf’
?: in function ‘_cachedRemoveSelf’
…
?: in function ‘_cachedRemoveSelf’
?: in function ‘removeSelf’
?: in function ‘remove’
…re/AppsSVN/Removed/widget_candy.lua:1202: in function ‘_RemoveWidget’
…re/AppsSVN/Removed/widget_candy.lua:593: in function ‘destroy’
…AppsSVN/Removed/recipecalscreen.lua:1847: in function ‘cleanUp’
…m Software/AppsSVN/Removed/main.lua:87: in function ‘loadScreen’
…m Software/AppsSVN/Removed/main.lua:110: in function ‘onRelease’
…com Software/AppsSVN/Removed/ui.lua:90: in function
?: in function
greg
发布于 17:01, 9月2日因此，返回 true 或 false.. 该文档有
“如果从 unhandledError 的监听器返回 true，则会抑制该错误，并且应用程序执行将继续。从监听器返回 false（或不返回任何内容）将允许向用户报告运行时错误并终止应用程序。”
那么这是否意味着如果你返回 false（或不返回任何内容），应用程序的行为将与你没有实现处理程序时的行为完全相同？因此，如果你的监听器中出现一些错误，但不会导致应用程序崩溃，并且用户仍然可以玩游戏，那么在实现此错误处理系统后，它将是相同的，但你的优势是有机会将其打印出来（或将其记录到 Flurry 中，例如）
在这种情况下，最安全的方法是返回 false（或不返回任何内容），对吗？