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