I've got some code that is occasionally exhibiting unexpected behavior that is hard to reproduce. I'm trying to see what is happening by running:
node --inspect client.js
It gives me a URL which I click, and then Chrome comes up with a console. Now I wait for the bad state to be encountered, and then I want to inspect the value of various variables in main.js (which are in term other objects I can dig into) in order to try to figure out what is going on.
However, I can't see any of my variables! I can see the global scope, but it has no variables from my code in it. How can I introspect the state of my program without having to think too far ahead, i.e. I could expose some variable to the global scope and hope that doesn't cause any side-effects, but then what if the issue is occurring somewhere I didn't think to expose? I want to set everything up and only have to run one time because this is a rather difficult problem to reproduce and may take a substantial amount of time, so once it gets into this state I have to be able to do everything I need to find the problem without losing the current program state.
Edit: Also to add, placing breakpoints is not necessarily helpful, because everything is event driven, and these is no guarantee I can trigger an event, or that it won't change the state in a way the interferes with trying to determine why the program is in a bad state, or that I can see the scope I need to look at from the scope where the event occurs.
Update: I tried adding a bit of code in my main module and then exporting all the top-level variables:
global.main=module
module.exports = {
var1:var1,
...
var99:var99
}
This part seemed to work ok, but I still don't have access the to internal state of objects. To accomplish this, I tried adding a debug function to each object which simply had a debugger statement to stop the debugger, like so:
function SomeOjbect(...) {
var me = this
...
me.debug = function() {
console.log("In debugger")
debugger
}
...
}
The theory being that at this point all the local variables closed to the object would be inspectable. However, when I hit the debug statement and get a breakpoint, the inspection tools completely ignore all my efforts to inspect variables in the object - in the console I get no output, just another prompt, while in the watch window after I type in the variable and hit enter it disappears completely, as if I never even tried to enter a new variable. This happens even if I mention the name of the variable in the code before hitting the debugger to try to prevent it from being optimized out, e.g. when I change the above code to this:
console.log("In debugger")
me;
debugger
I still am unable to inspect me. (It does, however, print me to the console if I replace me; with console.log(me)!)
Update: Actually, it appears that I'm able to do nothing at all in the breakpoint. If I enter console.log("Test") in the console, it doesn't output anything either. If I let the code continue running, the commands I entered into the console don't even show up in history, and in fact I no longer am able to enter any new commands at all, they all continue to be ignored, and sometimes in the source tab all source code vanishes and I pretty much have to shut down the running program and start over because the debugger becomes useless.
Related
How can ordinary, top level functions, that are part of the default closure be exposed to the JS console in the browser (for debugging reasons)?
// default.js
function iWantToCallThisFunction() {
console.log("test successfull");
}
There's this answer from 2014, which doesn't seem to be valid anymore: https://stackoverflow.com/a/9054881/6204346
At least a current Chrome can't find the function and defaults to undefined.
Flagging the function with export doesn't seem to make a difference. It would probably be possible but inconvenient to safe the function in the window. Is there a better way?
That's very strange that it's showing as undefined. If you want to view the contents of the function (and it's already loaded and declared) just type iWantToCallThisFunction without the parenthesis at the end. If you want to call the function, just type iWantToCallThisFunction() with parenthesis. You could also try setting the function as a variable. I think that this is because the function isn't actually being created by the time you go into the JavaScript console. Make sure the right JavaScript file is connected, and that there's no errors. If the file has other stuff in it, that might be interfering with this function being made, so maybe try it in a blank file by itself.
Google's Chrome browser has a nice feature which shows you the return value in the debugger before you step out of the function. It shows up in the Scope list in one of the debugger panes along with Watch, Call Stack, etc. It looks like this.
I'm curious if there's console access to this variable?
I frequently have a need to do something like this while debugging:
<return>.filter(function(z) { return z >= 0; })
Or any other arbitrary way to understand whether the return value was what I was expecting. Unfortunately, I can't find a way to refer to <return> in the console. I was hoping there was some variable like $_ that would give me access, but I haven't found look looking in the likely places.
I realize I can look at the <return> object as it appears in the Scope list but if the item is a large array or complex object, etc., I would prefer to type some code into the debugger while paused at a breakpoint to see if I'm getting what I expect.
What I typically resort to is modifying my code to save the return value to a variable, and then reproducing the steps to get back to the breakpoint, but this is annoying.
Thoughts?
Store as Global Variable works in google chrome now, using Version 56.0.2924.87.
So, you step to the close brace of your function in the Sources tab, then context-click the Return Value, and choose Store as Global Variable.
The console tab will show something like
temp1 = ▶ MyClass {...}
From there on you can access temp1 just like any other variable in the console.
Often the error in the console does not include a trace or error object, but just a simple message like :
object is undefined
length = object.length,
so I can't easily find the part of the app that is calling jquery with the faulty data.
At present I am tracking them down by entering a long trail of logs until I find the broken code. This is time consuming and is becoming more so as the app grows in complexity. Is there an easier way?
Edit: to add screenshot
In the console where you see the error:
click the circled part so that it becomes fully red:
then refresh the page. Firebug will break at the error, interrupting the execution of the script at that precise point.
You can now examine the stack trace (which includes the call stack), and use "Watch" to watch the value of variables.
in firebug you can write conlose.log(object name) then open the console you will get complete object.
Use debugger (inside the function calls where u expect to receive values from controller)inside the script.
I have seen jquery-ui-1.8.11.js verify console.log functionality by doing
if (this.debug)
console.log()
I have also seen people define an anonymous function that is a no-op for browsers with no console logging like IE7.
if(typeof console === "undefined") {
console = { log: function() { } };
}
Is there a technical difference or are both functionally equivalent?
In the first example you've given, this.debug will be a reference to a debug variable in the jQueryUI code. This debug variable will have been set elsewhere, possibly by checking whether console is defined, but also possibly with other settings.
In any case, the first example is specific to the application; if you want to do a generic check to see whether the console is available, you'll need to use the second technique. You don't have to define an empty console object as per the example, but doing it that way does mean that you won't have to do the if() condition every time you want to call console.log().
Having said all of that, I would counsel you strongly to avoid putting any code into production which contains calls to the console. The console should only be used for debugging purposes while you are working on the code. It should not be necessary in final release, and doing so can be a sign that either your code is unstable or you're unconfident of it, neither of which is a good sign if you're releasing the code for live use.
(libraries such as jQueryUI are an exception to this rule, as they need to provide functionality for developers to do debugging while writing code using their library)
Both of those do something else. The first code suppresses logging messages unless a flag is set. The people who develop jQuery UI need logging when working on it, and turn it on. But people using the library don't want to have their console cluttered by log messages from libraries, so it's off by default. It lets you turn off logging even when the browser supports it – that regular users on IE7 don't get script errors is a (possibly intended) side effect.
The second code defines a dummy console.log(), so you can call the method without checking if it exists everywhere. It will not suppress logging on browsers where it's supported.
The second of the two is standalone, not relying on jQuery. In my opinion, that makes it better.
I'm not a JavaScript Wizard by a long shot. But I am a web-developer and so I need to know my way around it at least a bit.
Something I'll often do is simply alert a variable to see what it is.
However, the problem is that I'll often get a result like: "object HTMLInputElement". To me this means little to nothing. Sure I can look it up, but I need to alert children() of children() of children(), etc...
I've tried walking through the JavaScript with Firebug, but for some reason this is very slow. Firefox hangs when I start a debug session, for every single debug session and I don't know why.
So, I want to inform if there is a way to get detailed info on variables some other way. Or a system I can use to work with to make things easier.
I find the developer tools in Chrome work quite well, giving a good amount of detail on demand (usually just hovering the mouse over the variable in the script tab; if that variable is a structured object, a little tree control appears and you can drill down). But then, I don't have your Firebug issue either (or at least, not often anymore).
Debugging with alert is very time-wasteful and, as you've found, frustrating; if at all possible I'd look at using a real debugger (like Chrome's Dev Tools; I've also heard good things about Opera's).
This should help:
http://www.openjs.com/scripts/others/dump_function_php_print_r.php
The easiest way to inspect a javascript variable is with a debugger. If Firebug is not working out for you try using Google Chrome, it has an inspector built in.
Btw - not sure what you mean by "start a debug session". If you have firebug installed, you should simply be able to click on the firebug icon on the bottom right of your browser. Go to the script tab, and select from the drop down whatever js file you want, stick in a break point (just left-click on the margin) and refresh the page. I've never had a problem with Firebug, it's always worked extremely well. I strongly advise figuring out whatever your issue with it is, it will make your life a million times easier.
Using any of the browser dev tools, including IE9, you can use console.log to get the variable output on the console. What information this gives you will vary by browser, but with Firebug it allows you to explore the variable in the DOM inspector tab, with full access to all properties and functions (you can even copy the content of a function to paste elsewhere).
For instance:
var foo = {};
// Do lots of stuff with foo
if (typeof(console) !== "undefined" && console.log) { // prevent errors when console not open, ideally all console calls should be removed before going into production
console.log(foo);
}
This has the advantage that it doesn't require any break points, so no slow step-debugging. It won't solve everything though, you'll often still need the debugger.