I'm trying to get a better understanding of how the publication / subscription model works.
Specifically I'm referring to this step in the tutorial.
if (Meteor.isServer) {
Meteor.publish('tasks', function tasksPublication() {
return Tasks.find();
});
}
The name tasksPublication isn't used anywhere later on in the tutorial.
Looking at the documentation here the name doesn't seem to be needed.
Does it make any difference to name a publication function?
Using named functions is indeed not needed when publishing, all these work:
Meteor.publish('tasks', function publishAllTasks() { return Tasks.find() });
Meteor.publish('tasks', function() { return Tasks.find() });
Meteor.publish('tasks', () => Tasks.find());
(The third line features an Arrow function)
There is no raw difference in functionality, and choosing between the three mostly boils down to taste.
However, there is one one thing that only the first statement (named function expression) does: the name appears in stack traces when an uncaught exception occurs.
For example let's say you make a typo when writing Tasks and write Waffles instead:
// File: server/index.js
Meteor.publish('tasks', function publishAllTasks() { return Waffles.find() });
// or:
Meteor.publish('tasks', () => Waffles.find());
Here is the stack trace in the first case (I removed timestamps)
Exception from sub tasks id egG3xJuLTLFvH4jLT ReferenceError: Waffles is not defined
at Subscription.publishAllTasks [as _handler] (server/index.js:4:10)
(some boring stuff)
Stack trace in the second case:
Exception from sub tasks id u4rKBFH78uTBEoys2 ReferenceError: Waffles is not defined
at Subscription._handler (server/index.js:4:10)
(more boring stuff)
In the first case the function name appears clearly.
The file name and line still appear at the end of the line.
So it could be helpful if you are crawling through your logs to find all uncaught exceptions that originated from / passed through publishAllTasks.
It won't help a lot when debugging though since you still have the file name and line and finding the faulty function is just a matter of opening that file.
So unless you have specific log-crawling needs don't bother and go for whichever you prefer.
I did notice a worrysome behaviour with node.js (v4.0.0).
I have an object with functions, something like this:
var local = {};
local.myMethod = function() {
console.log('here I am');
};
At a certain point in time I did comment out myMethod() for debugging purposes.
Some time later, I did call it again in my code, forgetting to remove comments from function definition:
...
var result = local.myMethod();
...
/*
local.myMethod = function() {
console.log('here I am');
};
*/
When running that code, I got no compile nor runtime error, so I got mad catching the silly problem...
What I ask is: Is this behaviour intended?
Should I use some pragma enforcing strictness, to avoid such problems?
UPDATE
Sorry, this code does not reproduce the problem, I did shrink it too much...
I'm quite sure on some condition the problem shows, however: I have a warning set just before the call to the undefined function... The warning prints, and then the code continues without a notice...
The undefined function is called inside an async.each() function, but I can't yet simplify my code enough to post it here... Keep trying...
To make debugging easier, I'm capturing all of the console logs in Chrome so that users who submit a feedback entry will also submit all of the logs to our server. When someone encounters a problem in production, I can first and foremost get them back to work so that I can then sit down and more thoroughly go through all of the logs to determine the root cause of whatever issue the user encountered in production.
The technique I use to capture the logs involves overriding console.log so that all text entered in the first argument gets stored in an array while simultaneously invoking the legacy function so that I can still see the logs in the console too.
The problem is when there's the occasional uncaught exception. These aren't included in the uploaded logs, so it's not always clear what caused the problem. So I tried overriding ReferenceError by writing a JavaScript function that takes a function as an argument, then returns a new function that does stuff with it, like storing data in a variable, and then invoking the legacy function as the last step:
function overrideException(legacyFn) {
/** arguments for original fn **/
return function() {
var args = [];
args[0] = arguments[0];
// pass in as arguments to original function and store result to
// prove we overrode the ReferenceError
output = ">> " + legacyFn.apply(this, args).stack;
return legacyFn.apply(this, arguments);
}
}
To test the overrideException function, I ran the following code on the console:
ReferenceError = overrideException(ReferenceError);
Afterwards, I tested the returned function, the new ReferenceError, by manually throwing a ReferenceError:
throw new ReferenceError("YES!! IT WORKS! HAHAHA!");
The resulting output on the console is:
ReferenceError: YES!! IT WORKS! HAHAHA!
And checking the global variable output from the overrideException function shows that it did indeed run:
output
">> ReferenceError: YES!! IT WORKS! HAHAHA!
at ReferenceError (<anonymous>)
at new <anonymous> (<anonymous>:18:35)
at <anonymous>:2:7
at Object.InjectedScript._evaluateOn (<anonymous>:562:39)
at Object.InjectedScript._evaluateAndWrap (<anonymous>:521:52)
at Object.InjectedScript.evaluate (<anonymous>:440:21)"
Now, here's where things start to fall apart. In our code, we're not going to know when an uncaught exception occurs, so I tested it by attempting to run a function that doesn't exist:
ttt();
Which results in:
ReferenceError: ttt is not defined
However, unlike the case where we explicitly throw an error, in this case, the function doesn't fire, and we're left with only the legacy functionality. The contents of the variable output is the same as in the first test.
So the question seems to be this: How do we override the ReferenceError functionality that the JavaScript engine uses to throw errors so that it's the same one we use when we throw a ReferenceError?
Keep in mind that my problem is limited only to Chrome at this time; I'm building a Chrome Packaged app.
I have done quite a bit of research for the same reason: I wanted to log errors and report them.
"Overriding" a native type (whether ReferenceError, String, or Array) is not possible.
Chrome binds these before any Javascript is run, so redefining window.ReferenceError has no effect.
You can extend ReferenceError with something like ReferenceError.prototype.extension = function() { return 0; }, or even override toString (for consistency, try it on the page, not the Dev Tools).
That doesn't help you much.
But not to worry....
(1) Use window.onerror to get file name, 1-indexed line number, and 0-indexed position of uncaught errors, as well as the error itself.
var errorData = [];
onerror = function(message, file, line, position, error) {
errorData.push({message:message, file:file, line:line, position:position, error:error});
};
See the fiddle for an example. Since the OP was Chrome-specific, this has only been tested to work in Chrome.
(2) Because of improvements to (1), this is no longer necessary, but I leave this second technique here for completeness, and since onerror is not guaranteed to work for all errors on all browsers. You will also sometimes see the following:
var errors = [];
function protectedFunction(f) {
return function() {
try {
f.apply(this, arguments);
} catch(e) {
errors.push(e);
throw e;
}
};
}
setTimeout = protectedFunction(setTimeout);
setInterval = protectedFunction(setInterval);
etc...
FYI, all this is very similar to what has been done in the Google Closure Compiler library, in goog.debug, created during Gmail development with the intent of doing exactly this. Of particular interest is goog.debug.ErrorHandler and goog.debug.ErrorReporter.
So I am I getting an error using tinyMCE but that isn't really the question here. I am trying to debug it using firebug and I am a little confused. I have a break point here.
This breakpoint gets hit when the page loads but then although the error says it is on line 564 I never see it get hit again (even though I can click save over and over and get the same error). Is that because of the way that function gets created? clearly JQuery is creating some sort of object literal with a bunch of functions as the value of the variables like
var functions = {
func1: function() {...},
func2: function() {...}
};
instead of saying
var myAwesomeFunction = function() { //do awesome };
I am not sure but if so how I can debug this?
Thanks
I'm trying to create a javascript object that can call other methods within itself. However, I'm running into a weird problem that I just can't seem to figure out.
I have the following code
myObjectDef = function() {
this.init = function() {
//do some stuff
this.doSecondInit();
}
this.doSecondInit = function() {
//do some more stuff
}
}
myObject = new myObjectDef();
myObject.init();
I am getting an error that states "Message: Object doesn't support this property or method". And it ends at this.doSecondInit();. I can't quite figure out why it's doing this. My code runs great up to the call to the second method. How do I make this work?
There's an extra set of parenthesis here:
this.doSecondInit() = function() {
You can't assign to the result of a function call, let alone to the result of a function that doesn't even exist.
After your edit, your thing seems to work fine:
http://jsfiddle.net/nabVN/
You sure you didn't have the same typo in your actual code? Better start getting used to not putting that () after every function call, which is probably a bad habit carried over from languages where functions aren't values.