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