一、为什么要做这么一个错误输出台？

事发起因：

策划A：今天晚上要出个热更包，明天10点热更一下，小改点东西，应该没什么大问题。
程序A：ok,马上。
【大约10分钟后】
程序A：我X，不行啊，报错了！
策划A：能查看一下错误日志吗？
程序A：这个游戏包是IOS很早就打出来的包，貌似并不能查看错误日志。
程序B：手动排查吧
【晚上12点后】
程序A：哎，终于找到原因了，原来是。。。

事发分析：
出现错误并不可怕，可怕的是对错误一无所知，不知道错误发生的起因。如果在错误发生时能够将错误及时展现出来，这样就能够最快的分析问题，解决问题。现在游戏测试的流程也是，测试测出游戏问题后，需要先拿着真机给程序看，然后程序模拟BUG的出现方式，出现后再修改，出不来，就只能等着下次碰巧出现。

事发总结：
现在需要一个错误输出台，当游戏出现BUG后，这个输出台能够及时的弹出，然后测试人员只需要截屏，然后发送给程序，就能够最快的获取到BUG信息，尽快的解决问题。

二、手动起来

因为cocos-js底层是通过spidermonkey提供对js的支持，所以就去查看一下spidermonkey，对于蜘蛛猴的介绍和使用，网上有很多资料，最近我也是在学习这块资料，
最终，我们在@H_404_29@ScriptingCore.cpp这个文件中找到了

JS_SetErrorReporter(_cx,ScriptingCore::reportError);

这么一行代码，网上查了下，确实是错误输出的地方，然后进到reportError这个方法中，

void ScriptingCore::reportError(JSContext *cx,const char *message,JSErrorReport *report)
{
    //-----------------------------wade-----------------------------//
    js_log("▄︻┻═┳一 龙︻▆▇◤ ︻Q▅▆▇◤ ︻1▅▆▇◤ ︻ф▅▅▆▇◤ o︻0▅▆▇◤ v︻▅▆▇◤");
    char* __log = (char *)calloc(sizeof(char),MAX_LOG_LENGTH+1);
    sprintf(__log,"file--->%s ||| line--->%u ||| info--->%s",report->filename ? report->filename : "<no filename=\"filename\">",(unsigned int) report->lineno,message);
    js_log(__log);
    js_log("▄︻┻═┳一 ︻7▅▆▇◤ ︻╃▅▆▇◤ ━━━X▅▆▇◤ ︻AS▅▆▇◤ s︻b▅▆▇◤ ︻v▅▆▇◤");

    //取消掉JS出错的异常(！这句如果不调用，那么，下面C++调用JS的时候会一直报之前的异常，引发递归问题)
    JS_ClearPendingException(cx);

    //c++调用js代码，在js中定义了gReportError这么个方法，出错的时候会调用，并传参__log
    char* char_content = (char *)calloc(sizeof(char),MAX_LOG_LENGTH+1);
    sprintf(char_content,"gReportError('%s')",__log);
    ScriptingCore::getInstance()->evalString(char_content,NULL);    
}

三、效果演示

四、后期改善

游戏中出错了，可以及时发现，但是只有在debug开关为true时才能呈现出来，而正式的上线包这个开关是false的，所以当玩家发现错误的时候还是不能及时发现，还是需要程序模拟线上环境，然后发现问题，才能解决问题。 我们就想这个开关能不能手动打开，所以就想到了输入框，当我们在输入框中输入一段特殊的口令时，这时dubug开关就打开，然后就可以查看错误了，我们想到了我们的激活码输入框，这样我们的错误输出台就算在线上正式环境上也可以显示出来啦！