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

Reply via email to