You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@whimsical.apache.org by sebb <se...@gmail.com> on 2017/06/10 13:43:17 UTC
Missing context for Ruby errors
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?
Re: Missing context for Ruby errors
Posted by sebb <se...@gmail.com>.
On 12 June 2017 at 11:28, Sam Ruby <ru...@intertwingly.net> wrote:
> On Mon, Jun 12, 2017 at 5:29 AM, sebb <se...@gmail.com> wrote:
>> On 12 June 2017 at 03:36, Sam Ruby <ru...@intertwingly.net> wrote:
>>> On Sun, Jun 11, 2017 at 7:16 PM, sebb <se...@gmail.com> wrote:
>>>> On 11 June 2017 at 00:14, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>> On Sat, Jun 10, 2017 at 6:39 PM, sebb <se...@gmail.com> wrote:
>>>>>> On 10 June 2017 at 23:20, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>>>> On Sat, Jun 10, 2017 at 6:15 PM, sebb <se...@gmail.com> wrote:
>>>>>>>> On 10 June 2017 at 17:22, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>>>>>> On Sat, Jun 10, 2017 at 12:05 PM, sebb <se...@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 <se...@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 <se...@gmail.com> wrote:
>>>
>>> [snip]
>>>
>>>>>>
>>>>>> I don't know where to start with ExecJS.
>>>>>
>>>>> Neither do I.
>>>>>
>>>>>> But it ought to be possible to use window.onerror or similar in the
>>>>>> generated code to catch/display the error to the user.
>>>>>
>>>>> There is no window object on the server.
>>>>>
>>>>>> Or wrap the generated JS in try/catch.
>>>>>
>>>>> And do what?
>>>>
>>>> Display err.stack
>>>>
>>>> for example:
>>>>
>>>> try {
>>>> ...
>>>> } catch(err) {
>>>> alert(err.stack);
>>>> console.log(err.stack);
>>>> etc.
>>>> }
>>>>
>>>> However I've no idea how to add that to the generated code.
>>>>
>>>> It might be worth seeing what the following gives:
>>>>
>>>> rescue ExecJS::ProgramError => e
>>>> Wunderbar.error e.inspect
>>>>
>>>> It may be that the error object has more info embedded.
>>>
>>> With no window object on the server, there is no window.alert. There
>>> is no console object on the server either. Lets try this the other
>>> way. I've included a sample program below with no dependencies other
>>> than execjs:
>>>
>>> require 'execjs'
>>>
>>> source = %{
>>> function test () {
>>> try {
>>> var x = null;
>>> x.y();
>>> } catch(err) {
>>> alert(err.stack);
>>> console.log(err.stack);
>>> }
>>> }
>>> }
>>>
>>> context = ExecJS.compile(source);
>>> context.call("test()");
>>
>> Running that with ruby fails with the error:
>>
>> test ((execjs):7:7): ReferenceError: alert is not defined (ExecJS::ProgramError)
>>
>> However the generated app.js file contains code of the form:
>>
>> .catch(function(error) {
>> alert(errror);
>> jQuery("#confirm").modal("hide");
>> self.setState({disabled: false})
>>
>> which *does* use alert.
>
> That code is contained within logic that is known to only run on the client.
>
>> Though why it uses errror instead of error is unclear.
>
> Clearly a typo on my part. I've pushed a fix. Good catch!
>
>> I don't know how the alert gets added to the generated js, but if that
>> could be updated to change the alert and/or wrap the code in a
>> try/catch block it might solve the issue.
>
> If you look at the fix I just pushed, you will see the code that gets
> translated into the code mentioned above.
>
> As to adding another try/catch block: again the question is do what
> within that try/catch block? On the client, you get a nice traceback
> in your console. On the server, there is no access to an alert or
> console.log function.
>
>> ==
>>
>> As to improving the server code reporting, it looks as though it may
>> be sufficient to add
>>
>> Wunderbar.error e.backtrace
>
> Getting a stack traceback of the ruby stack will only tell you that
> you are calling render. At most, it will help you identify which page
> the error occurred on, information that already is in the server log.
But as I noted earlier, it's not at all obvious how to find that info
from the error message.
There are various lines containing file names/URLs, but there's no
obvious connection with the error message except they have the same
App number.
It would help if:
1) the error was identified as a JS error
2) the source file was logged as wll.
> There would be value in showing a javascript traceback, but to date
> I've not figured out a way to do that. If you experiment with the
> smalls script I provided and find a way to show the javascript
> traceback with that code, I would be very interested.
I cannot get the sample code to run successfully, even without forced errors.
I tried
>>>
require 'execjs'
source = %{
function test() {
return 123;
}
}
context = ExecJS.compile(source);
context.call("test()");
<<<
And I get
eval (eval at <anonymous> ((execjs):6:8), <anonymous>:1:9): TypeError:
test(...).apply is not a function (ExecJS::ProgramError)
I have now found I get a better result with:
puts context.eval('test()'); => 123
which seems closer to what Wunderbar does.
However adding alert to the JS source breaks the compilation.
Yet Wunderbar clearly is able to generate JS containing an alert call.
Another aspect I don't understand is why the code is executed on the server.
I would expect it to be generated on the server and then returned to
the client for evaluation.
>> after
>>
>> https://github.com/rubys/wunderbar/blob/master/lib/wunderbar/react.rb#L133
>>
>>> - Sam Ruby
>
> - Sam Ruby
Re: Missing context for Ruby errors
Posted by Sam Ruby <ru...@intertwingly.net>.
On Mon, Jun 12, 2017 at 5:29 AM, sebb <se...@gmail.com> wrote:
> On 12 June 2017 at 03:36, Sam Ruby <ru...@intertwingly.net> wrote:
>> On Sun, Jun 11, 2017 at 7:16 PM, sebb <se...@gmail.com> wrote:
>>> On 11 June 2017 at 00:14, Sam Ruby <ru...@intertwingly.net> wrote:
>>>> On Sat, Jun 10, 2017 at 6:39 PM, sebb <se...@gmail.com> wrote:
>>>>> On 10 June 2017 at 23:20, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>>> On Sat, Jun 10, 2017 at 6:15 PM, sebb <se...@gmail.com> wrote:
>>>>>>> On 10 June 2017 at 17:22, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>>>>> On Sat, Jun 10, 2017 at 12:05 PM, sebb <se...@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 <se...@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 <se...@gmail.com> wrote:
>>
>> [snip]
>>
>>>>>
>>>>> I don't know where to start with ExecJS.
>>>>
>>>> Neither do I.
>>>>
>>>>> But it ought to be possible to use window.onerror or similar in the
>>>>> generated code to catch/display the error to the user.
>>>>
>>>> There is no window object on the server.
>>>>
>>>>> Or wrap the generated JS in try/catch.
>>>>
>>>> And do what?
>>>
>>> Display err.stack
>>>
>>> for example:
>>>
>>> try {
>>> ...
>>> } catch(err) {
>>> alert(err.stack);
>>> console.log(err.stack);
>>> etc.
>>> }
>>>
>>> However I've no idea how to add that to the generated code.
>>>
>>> It might be worth seeing what the following gives:
>>>
>>> rescue ExecJS::ProgramError => e
>>> Wunderbar.error e.inspect
>>>
>>> It may be that the error object has more info embedded.
>>
>> With no window object on the server, there is no window.alert. There
>> is no console object on the server either. Lets try this the other
>> way. I've included a sample program below with no dependencies other
>> than execjs:
>>
>> require 'execjs'
>>
>> source = %{
>> function test () {
>> try {
>> var x = null;
>> x.y();
>> } catch(err) {
>> alert(err.stack);
>> console.log(err.stack);
>> }
>> }
>> }
>>
>> context = ExecJS.compile(source);
>> context.call("test()");
>
> Running that with ruby fails with the error:
>
> test ((execjs):7:7): ReferenceError: alert is not defined (ExecJS::ProgramError)
>
> However the generated app.js file contains code of the form:
>
> .catch(function(error) {
> alert(errror);
> jQuery("#confirm").modal("hide");
> self.setState({disabled: false})
>
> which *does* use alert.
That code is contained within logic that is known to only run on the client.
> Though why it uses errror instead of error is unclear.
Clearly a typo on my part. I've pushed a fix. Good catch!
> I don't know how the alert gets added to the generated js, but if that
> could be updated to change the alert and/or wrap the code in a
> try/catch block it might solve the issue.
If you look at the fix I just pushed, you will see the code that gets
translated into the code mentioned above.
As to adding another try/catch block: again the question is do what
within that try/catch block? On the client, you get a nice traceback
in your console. On the server, there is no access to an alert or
console.log function.
> ==
>
> As to improving the server code reporting, it looks as though it may
> be sufficient to add
>
> Wunderbar.error e.backtrace
Getting a stack traceback of the ruby stack will only tell you that
you are calling render. At most, it will help you identify which page
the error occurred on, information that already is in the server log.
There would be value in showing a javascript traceback, but to date
I've not figured out a way to do that. If you experiment with the
smalls script I provided and find a way to show the javascript
traceback with that code, I would be very interested.
> after
>
> https://github.com/rubys/wunderbar/blob/master/lib/wunderbar/react.rb#L133
>
>> - Sam Ruby
- Sam Ruby
Re: Missing context for Ruby errors
Posted by sebb <se...@gmail.com>.
On 12 June 2017 at 03:36, Sam Ruby <ru...@intertwingly.net> wrote:
> On Sun, Jun 11, 2017 at 7:16 PM, sebb <se...@gmail.com> wrote:
>> On 11 June 2017 at 00:14, Sam Ruby <ru...@intertwingly.net> wrote:
>>> On Sat, Jun 10, 2017 at 6:39 PM, sebb <se...@gmail.com> wrote:
>>>> On 10 June 2017 at 23:20, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>> On Sat, Jun 10, 2017 at 6:15 PM, sebb <se...@gmail.com> wrote:
>>>>>> On 10 June 2017 at 17:22, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>>>> On Sat, Jun 10, 2017 at 12:05 PM, sebb <se...@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 <se...@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 <se...@gmail.com> wrote:
>
> [snip]
>
>>>>
>>>> I don't know where to start with ExecJS.
>>>
>>> Neither do I.
>>>
>>>> But it ought to be possible to use window.onerror or similar in the
>>>> generated code to catch/display the error to the user.
>>>
>>> There is no window object on the server.
>>>
>>>> Or wrap the generated JS in try/catch.
>>>
>>> And do what?
>>
>> Display err.stack
>>
>> for example:
>>
>> try {
>> ...
>> } catch(err) {
>> alert(err.stack);
>> console.log(err.stack);
>> etc.
>> }
>>
>> However I've no idea how to add that to the generated code.
>>
>> It might be worth seeing what the following gives:
>>
>> rescue ExecJS::ProgramError => e
>> Wunderbar.error e.inspect
>>
>> It may be that the error object has more info embedded.
>
> With no window object on the server, there is no window.alert. There
> is no console object on the server either. Lets try this the other
> way. I've included a sample program below with no dependencies other
> than execjs:
>
> require 'execjs'
>
> source = %{
> function test () {
> try {
> var x = null;
> x.y();
> } catch(err) {
> alert(err.stack);
> console.log(err.stack);
> }
> }
> }
>
> context = ExecJS.compile(source);
> context.call("test()");
Running that with ruby fails with the error:
test ((execjs):7:7): ReferenceError: alert is not defined (ExecJS::ProgramError)
However the generated app.js file contains code of the form:
.catch(function(error) {
alert(errror);
jQuery("#confirm").modal("hide");
self.setState({disabled: false})
which *does* use alert.
Though why it uses errror instead of error is unclear.
I don't know how the alert gets added to the generated js, but if that
could be updated to change the alert and/or wrap the code in a
try/catch block it might solve the issue.
==
As to improving the server code reporting, it looks as though it may
be sufficient to add
Wunderbar.error e.backtrace
after
https://github.com/rubys/wunderbar/blob/master/lib/wunderbar/react.rb#L133
> - Sam Ruby
Re: Missing context for Ruby errors
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sun, Jun 11, 2017 at 7:16 PM, sebb <se...@gmail.com> wrote:
> On 11 June 2017 at 00:14, Sam Ruby <ru...@intertwingly.net> wrote:
>> On Sat, Jun 10, 2017 at 6:39 PM, sebb <se...@gmail.com> wrote:
>>> On 10 June 2017 at 23:20, Sam Ruby <ru...@intertwingly.net> wrote:
>>>> On Sat, Jun 10, 2017 at 6:15 PM, sebb <se...@gmail.com> wrote:
>>>>> On 10 June 2017 at 17:22, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>>> On Sat, Jun 10, 2017 at 12:05 PM, sebb <se...@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 <se...@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 <se...@gmail.com> wrote:
[snip]
>>>
>>> I don't know where to start with ExecJS.
>>
>> Neither do I.
>>
>>> But it ought to be possible to use window.onerror or similar in the
>>> generated code to catch/display the error to the user.
>>
>> There is no window object on the server.
>>
>>> Or wrap the generated JS in try/catch.
>>
>> And do what?
>
> Display err.stack
>
> for example:
>
> try {
> ...
> } catch(err) {
> alert(err.stack);
> console.log(err.stack);
> etc.
> }
>
> However I've no idea how to add that to the generated code.
>
> It might be worth seeing what the following gives:
>
> rescue ExecJS::ProgramError => e
> Wunderbar.error e.inspect
>
> It may be that the error object has more info embedded.
With no window object on the server, there is no window.alert. There
is no console object on the server either. Lets try this the other
way. I've included a sample program below with no dependencies other
than execjs:
require 'execjs'
source = %{
function test () {
try {
var x = null;
x.y();
} catch(err) {
alert(err.stack);
console.log(err.stack);
}
}
}
context = ExecJS.compile(source);
context.call("test()");
- Sam Ruby
Re: Missing context for Ruby errors
Posted by sebb <se...@gmail.com>.
On 11 June 2017 at 00:14, Sam Ruby <ru...@intertwingly.net> wrote:
> On Sat, Jun 10, 2017 at 6:39 PM, sebb <se...@gmail.com> wrote:
>> On 10 June 2017 at 23:20, Sam Ruby <ru...@intertwingly.net> wrote:
>>> On Sat, Jun 10, 2017 at 6:15 PM, sebb <se...@gmail.com> wrote:
>>>> On 10 June 2017 at 17:22, Sam Ruby <ru...@intertwingly.net> wrote:
>>>>> On Sat, Jun 10, 2017 at 12:05 PM, sebb <se...@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 <se...@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 <se...@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 <se...@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
>>>>
>>>> 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.
>
> Neither do I.
>
>> But it ought to be possible to use window.onerror or similar in the
>> generated code to catch/display the error to the user.
>
> There is no window object on the server.
>
>> Or wrap the generated JS in try/catch.
>
> And do what?
Display err.stack
for example:
try {
...
} catch(err) {
alert(err.stack);
console.log(err.stack);
etc.
}
However I've no idea how to add that to the generated code.
It might be worth seeing what the following gives:
rescue ExecJS::ProgramError => e
Wunderbar.error e.inspect
It may be that the error object has more info embedded.
> I encourage you to experiment.
>
> I'd like to do better. I just don't know how.
>
> - Sam Ruby
>
>>> - 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
Re: Missing context for Ruby errors
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Jun 10, 2017 at 6:39 PM, sebb <se...@gmail.com> wrote:
> On 10 June 2017 at 23:20, Sam Ruby <ru...@intertwingly.net> wrote:
>> On Sat, Jun 10, 2017 at 6:15 PM, sebb <se...@gmail.com> wrote:
>>> On 10 June 2017 at 17:22, Sam Ruby <ru...@intertwingly.net> wrote:
>>>> On Sat, Jun 10, 2017 at 12:05 PM, sebb <se...@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 <se...@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 <se...@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 <se...@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
>>>
>>> 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.
Neither do I.
> But it ought to be possible to use window.onerror or similar in the
> generated code to catch/display the error to the user.
There is no window object on the server.
> Or wrap the generated JS in try/catch.
And do what?
I encourage you to experiment.
I'd like to do better. I just don't know how.
- Sam Ruby
>> - 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
Re: Missing context for Ruby errors
Posted by sebb <se...@gmail.com>.
On 10 June 2017 at 23:20, Sam Ruby <ru...@intertwingly.net> wrote:
> On Sat, Jun 10, 2017 at 6:15 PM, sebb <se...@gmail.com> wrote:
>> On 10 June 2017 at 17:22, Sam Ruby <ru...@intertwingly.net> wrote:
>>> On Sat, Jun 10, 2017 at 12:05 PM, sebb <se...@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 <se...@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 <se...@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 <se...@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
>>
>> 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
Re: Missing context for Ruby errors
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Jun 10, 2017 at 6:15 PM, sebb <se...@gmail.com> wrote:
> On 10 June 2017 at 17:22, Sam Ruby <ru...@intertwingly.net> wrote:
>> On Sat, Jun 10, 2017 at 12:05 PM, sebb <se...@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 <se...@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 <se...@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 <se...@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
>
> 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.
- 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
Re: Missing context for Ruby errors
Posted by sebb <se...@gmail.com>.
On 10 June 2017 at 17:22, Sam Ruby <ru...@intertwingly.net> wrote:
> On Sat, Jun 10, 2017 at 12:05 PM, sebb <se...@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 <se...@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 <se...@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 <se...@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
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.
> - 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
Re: Missing context for Ruby errors
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Jun 10, 2017 at 12:05 PM, sebb <se...@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 <se...@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 <se...@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 <se...@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
Re: Missing context for Ruby errors
Posted by sebb <se...@gmail.com>.
On 10 June 2017 at 16:58, Sam Ruby <ru...@intertwingly.net> wrote:
> On Sat, Jun 10, 2017 at 11:48 AM, sebb <se...@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 <se...@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 <se...@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
Re: Missing context for Ruby errors
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Jun 10, 2017 at 11:48 AM, sebb <se...@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 <se...@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 <se...@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?).
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
Re: Missing context for Ruby errors
Posted by sebb <se...@gmail.com>.
On 10 June 2017 at 15:57, Sam Ruby <ru...@intertwingly.net> wrote:
> On Sat, Jun 10, 2017 at 10:27 AM, sebb <se...@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 <se...@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?
>>> 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
Re: Missing context for Ruby errors
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Jun 10, 2017 at 10:57 AM, Sam Ruby <ru...@intertwingly.net> wrote:
> On Sat, Jun 10, 2017 at 10:27 AM, sebb <se...@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 <se...@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
In converting to Vue, I dropped the ExecJS dependency. Instead of
calling out to "a" JavaScript runtime on the server, I'm specifically
shelling out to nodejs. This enables me to capture stderr, which I
send both to the server logs and insert into the HTML sent to the
client.
https://github.com/rubys/wunderbar/blob/master/lib/wunderbar/vue.rb#L31
Note: you may need to do a view-source to see this result on the
client as Vue is likely to remove these DOM nodes quickly.
>>> 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
Re: Missing context for Ruby errors
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Jun 10, 2017 at 10:27 AM, sebb <se...@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 <se...@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
>> 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
Re: Missing context for Ruby errors
Posted by sebb <se...@gmail.com>.
On 10 June 2017 at 15:20, Sam Ruby <ru...@intertwingly.net> wrote:
> On Sat, Jun 10, 2017 at 9:43 AM, sebb <se...@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?
> 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
Re: Missing context for Ruby errors
Posted by Sam Ruby <ru...@intertwingly.net>.
On Sat, Jun 10, 2017 at 9:43 AM, sebb <se...@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.
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