On 10 June 2017 at 23:20, Sam Ruby <[email protected]> wrote: > On Sat, Jun 10, 2017 at 6:15 PM, sebb <[email protected]> wrote: >> On 10 June 2017 at 17:22, Sam Ruby <[email protected]> wrote: >>> On Sat, Jun 10, 2017 at 12:05 PM, sebb <[email protected]> wrote: >>>> On 10 June 2017 at 16:58, Sam Ruby <[email protected]> wrote: >>>>> On Sat, Jun 10, 2017 at 11:48 AM, sebb <[email protected]> wrote: >>>>>> On 10 June 2017 at 15:57, Sam Ruby <[email protected]> wrote: >>>>>>> On Sat, Jun 10, 2017 at 10:27 AM, sebb <[email protected]> wrote: >>>>>>>> On 10 June 2017 at 15:20, Sam Ruby <[email protected]> wrote: >>>>>>>>> On Sat, Jun 10, 2017 at 9:43 AM, sebb <[email protected]> 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. But it ought to be possible to use window.onerror or similar in the generated code to catch/display the error to the user. Or wrap the generated JS in try/catch. > - 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
