33 lines
1.5 KiB
Org Mode
33 lines
1.5 KiB
Org Mode
|
* Q4
|
||
|
The ECMAScript 5 condition doesn't matter if we do not use strict.
|
||
|
If, we do:
|
||
|
let firstName = "jack"
|
||
|
console.log(firstname);
|
||
|
We will get an error for refering to a variable that currently exists.
|
||
|
However, if by "refered" they mean "try to reassign" then the answer would be different
|
||
|
The answer would be that firstname would be treated as a global, but that answer is not an option here.
|
||
|
B and D refer to a variable that doesn't exst in the question,
|
||
|
and C... I'm pretty sure Javascript has always been case sensitive
|
||
|
|
||
|
* Q7
|
||
|
Both B and C are possible.
|
||
|
Actually, in retrospect, that could only be a logic error.
|
||
|
A runtime error would not produce results
|
||
|
* Q8
|
||
|
I don't see why both a and be couldn't be true
|
||
|
* Q10
|
||
|
I don't recall learning this. Perhaps it was mentioned in a video, but I couldn't find this answer.
|
||
|
(Can't see the answers yet) My initial thought was that the W3C answer was
|
||
|
the correct one, but a later question chaged my oppinion on that.
|
||
|
* Q19
|
||
|
Step into google claims goes to the next statement (prolly executes too so I choose that one)
|
||
|
Step out finishes up the current function and pauses at the next, so fail.
|
||
|
Conitnue doesn't seem to exist fail
|
||
|
Step Over does not skip the next statement, it executes the next line and jumps to the next line... whatever that means.
|
||
|
In anycase, fail
|
||
|
|
||
|
So I'm left with the first which also seems like a fail, but I think google documentation was just poor.
|
||
|
|
||
|
Oh yea, this is all https://developers.google.com/web/tools/chrome-devtools/javascript/step-code
|
||
|
|