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? 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
