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