On 11 June 2017 at 00:14, Sam Ruby <ru...@intertwingly.net> wrote:
> On Sat, Jun 10, 2017 at 6:39 PM, sebb <seb...@gmail.com> wrote:
>> On 10 June 2017 at 23:20, Sam Ruby <ru...@intertwingly.net> wrote:
>>> On Sat, Jun 10, 2017 at 6:15 PM, sebb <seb...@gmail.com> wrote:
>>>> On 10 June 2017 at 17:22, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>> On Sat, Jun 10, 2017 at 12:05 PM, sebb <seb...@gmail.com> wrote:
>>>>>> On 10 June 2017 at 16:58, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>>>> On Sat, Jun 10, 2017 at 11:48 AM, sebb <seb...@gmail.com> wrote:
>>>>>>>> On 10 June 2017 at 15:57, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>>>>>> On Sat, Jun 10, 2017 at 10:27 AM, sebb <seb...@gmail.com> wrote:
>>>>>>>>>> On 10 June 2017 at 15:20, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>>>>>>>> On Sat, Jun 10, 2017 at 9:43 AM, sebb <seb...@gmail.com> wrote:
>>>>>>>>>>>> Hard to trace entry in error.log:
>>>>>>>>>>>>
>>>>>>>>>>>> App 11526 stderr: _ERROR TypeError: Cannot read property
>>>>>>>>>>>> 'proposal' of null
>>>>>>>>>>>>
>>>>>>>>>>>> The above error was fixed by cf054fd
>>>>>>>>>>>>
>>>>>>>>>>>> However finding the location of the error is not trivial, as there
>>>>>>>>>>>> is
>>>>>>>>>>>> no obvious context.
>>>>>>>>>>>>
>>>>>>>>>>>> Most other Ruby errors are reported with a stack trace and line
>>>>>>>>>>>> numbers - why is this error different?
>>>>>>>>>>>> Can it be fixed to produce a more detailed error message?
>>>>>>>>>>>
>>>>>>>>>>> It is different in that it actually is a JavaScript error.
>>>>>>>>>>>
>>>>>>>>>>> A number of whimsy applications use react.js in a number of pages
>>>>>>>>>>> (many roster pages, all board agenda pages). If you view source on
>>>>>>>>>>> those pages, you will see a static rendering, then the loading of
>>>>>>>>>>> javascript files, then the data the scripts need.
>>>>>>>>>>>
>>>>>>>>>>> The static rendering is done by running the JavaScript application
>>>>>>>>>>> on
>>>>>>>>>>> the server and inserting its output into the page. That application
>>>>>>>>>>> may fail, which is what happened here.
>>>>>>>>>>
>>>>>>>>>> Can't such errors be caught by the code that runs JavaScript?
>>>>>>>>>
>>>>>>>>> I suspect that that would either require a change to ExecJS or for
>>>>>>>>> Wunderbar to use an alternative to ExecJS. Here is the relevant
>>>>>>>>> Wunderbar code:
>>>>>>>>>
>>>>>>>>> https://github.com/rubys/wunderbar/blob/master/lib/wunderbar/react.rb#L125
>>>>>>>>
>>>>>>>> There's a rescue clause here:
>>>>>>>>
>>>>>>>> https://github.com/rubys/wunderbar/blob/master/lib/wunderbar/react.rb#L133
>>>>>>>>
>>>>>>>> Is that catching all possible errors, or are some not catchable here?
>>>>>>>
>>>>>>> It is catching the error, and printing out the one line you are
>>>>>>> seeing. What is missing is anything resembling a stack traceback -
>>>>>>> which I presumed was the context you were originally looking for (see
>>>>>>> subject line?).
>>>>>>
>>>>>> Yes.
>>>>>>
>>>>>> If Wunderbar has control over what is printed, then surely it can add
>>>>>> some more context?
>>>>>> Eg the name of the file it is processing?
>>>>>
>>>>> I'm still not following.
>>>>>
>>>>> In the case of the Roster tool, here's the input:
>>>>>
>>>>> https://github.com/apache/whimsy/blob/master/www/roster/views/ppmc.html.rb
>>>>
>>>> This is not obvious from the error log
>>>>
>>>>> So, the name of the file being processed is 'app.js'. Here it is:
>>>>>
>>>>> https://github.com/apache/whimsy/blob/master/www/roster/views/app.js.rb
>>>>>
>>>>> Here's the generated javascript, which is run on both the client and
>>>>> server:
>>>>>
>>>>> https://whimsy.apache.org/roster/app.js
>>>>>
>>>>> The error you saw occurred some place in that generated file.
>>>>>
>>>>> It is not clear to me how logging the name 'app.js' would help with
>>>>> debugging.
>>>>>
>>>>> Knowing the page that failed would be more useful, but that already is
>>>>> in the log.
>>>>
>>>> Is it?
>>>>
>>>> A sample log extract shows:
>>>>
>>>> App 11526 stderr: 71.168.148.85 - johndament [10/Jun/2017:12:35:34
>>>> +0000] "GET / HTTP/1.1" 304 - 1.6687
>>>> App 11526 stderr: 71.168.148.85 - johndament [10/Jun/2017:12:35:36
>>>> +0000] "GET /ppmc/ HTTP/1.1" 200 - 0.1865
>>>> App 11526 stderr: _ERROR TypeError: Cannot read property 'proposal' of null
>>>> App 11526 stderr: 71.168.148.85 - johndament [10/Jun/2017:12:35:40
>>>> +0000] "GET /ppmc/ariatosca HTTP/1.1" 200 - 1.8059
>>>> App 11526 stderr: 71.168.148.85 - johndament [10/Jun/2017:12:35:40
>>>> +0000] "GET /app.js HTTP/1.1" 200 - 0.0036
>>>> App 11526 stderr: 71.168.148.85 - johndament [10/Jun/2017:12:54:49
>>>> +0000] "GET / HTTP/1.1" 304 - 1.3152
>>>> App 11526 stderr: 71.168.148.85 - johndament [10/Jun/2017:12:54:53
>>>> +0000] "GET /ppmc/ HTTP/1.1" 304 - 0.1825
>>>> App 11526 stderr: _ERROR TypeError: Cannot read property 'proposal' of null
>>>> App 11526 stderr: 71.168.148.85 - johndament [10/Jun/2017:12:54:55
>>>> +0000] "GET /ppmc/ariatosca HTTP/1.1" 304 - 1.0298
>>>> App 11526 stderr: 71.168.148.85 - johndament [10/Jun/2017:12:54:56
>>>> +0000] "GET /app.js HTTP/1.1" 304 - 0.0004
>>>> App 11526 stderr: _ERROR TypeError: Cannot read property 'proposal' of null
>>>> App 11526 stderr: 98.122.169.124 - rubys [10/Jun/2017:13:02:40 +0000]
>>>> "GET /ppmc/atlas HTTP/1.1" 200 - 0.5462
>>>> App 11526 stderr: 98.122.169.124 - rubys [10/Jun/2017:13:02:41 +0000]
>>>> "GET /stylesheets/app.css HTTP/1.1" 200 - 0.0007
>>>> App 11526 stderr: 98.122.169.124 - rubys [10/Jun/2017:13:02:41 +0000]
>>>> "GET /app.js HTTP/1.1" 200 - 0.0032
>>>>
>>>> It's not at all obvious how to debug that, except that it is probably
>>>> associated with the /ppmc/ URL
>>>>
>>>> There's no indication that the error is a Javascript error.
>>>> Nor how to find the script that generated the Javascript
>>>>
>>>> When I tried forcing an error, the Javascript console shows:
>>>>
>>>> Uncaught TypeError: Cannot read property 'length' of undefined
>>>> at main.js.rb:144
>>>> ....
>>>>
>>>> But the screen only shows 'TypeError: Cannot read property 'length' of
>>>> undefined'
>>>>
>>>> and the log likewise.
>>>>
>>>> I would expect the log (and possibly the screen) to show the first
>>>> part of the stack trace.
>>>
>>> As I said, I know of no way to get any more information out of ExecJS.
>>> If you know of a way to get more information out, or know of a viable
>>> alternative to, ExecJS, please educate me.
>>
>> I don't know where to start with ExecJS.
>
> Neither do I.
>
>> But it ought to be possible to use window.onerror or similar in the
>> generated code to catch/display the error to the user.
>
> There is no window object on the server.
>
>> Or wrap the generated JS in try/catch.
>
> And do what?
Display err.stack
for example:
try {
...
} catch(err) {
alert(err.stack);
console.log(err.stack);
etc.
}
However I've no idea how to add that to the generated code.
It might be worth seeing what the following gives:
rescue ExecJS::ProgramError => e
Wunderbar.error e.inspect
It may be that the error object has more info embedded.
> I encourage you to experiment.
>
> I'd like to do better. I just don't know how.
>
> - Sam Ruby
>
>>> - Sam Ruby
>>>
>>>>>>> Or am I misunderstanding what you are looking for?
>>>>>>>
>>>>>>>>>>> Generally, the easiest way to debug such situations is to bring the
>>>>>>>>>>> page up in the browser and look at the error console. It used to be
>>>>>>>>>>> the case that in both Firefox and Chrome, you could click on the
>>>>>>>>>>> stack
>>>>>>>>>>> traceback in the console to see the original source; but for
>>>>>>>>>>> reasons I
>>>>>>>>>>> don't understand, with the current FIrefox you see the generated
>>>>>>>>>>> JavaScript instead.
>>>>>>>>>>>
>>>>>>>>>>> - Sam Ruby
>>>>>>>>>
>>>>>>>>> - Sam Ruby
>>>>>>>
>>>>>>> - Sam Ruby
