Pass the Salesforce Salesforce Developer JavaScript-Developer-I Questions and answers with CertsForce

The correct answer is A .

This object uses a getter :

get fullName() {

return this.firstName + ' ' + this.lastName;

}

A getter looks like a method when it is defined, but it is accessed like a normal property.

So the correct access syntax is:

dog.fullName

That returns:

" Beau Boo "

The important distinction is:

dog.fullName

not:

dog.fullName()

Because fullName is a getter property, not a regular function property.

Option B is incorrect because calling dog.fullName() tries to call the returned string as a function. Since " Beau Boo " is not a function, that would cause a TypeError.

Option C is incorrect because there is no get object inside dog.

Option D is incorrect because there is no function object inside dog, and getters are not accessed that way.

Therefore, the verified answer is A .

The code:

let timerId = setInterval(timedFunction, 1000);

setInterval schedules timedFunction to run every 1000 ms.

It returns an interval ID (here stored in timerId), which is used to cancel the interval later.

To cancel:

Use clearInterval(timerId);

This is the standard browser (and Node.js) API:

let id = setInterval(fn, delay);

clearInterval(id); stops future executions of that interval.

Check other options:

B. removeInterval(timerId);

There is no removeInterval function in the standard JavaScript timer API.

C. removeInterval(timedFunction);

Again, no such function; and timers are cancelled by ID, not by the callback function reference.

D. clearInterval(timedFunction);

clearInterval expects the ID returned by setInterval, not the callback function.

Passing the function does not cancel the timer.

Therefore, the correct statement is:

Answer: A

Study Guide / Concept References (no links):

Timer APIs: setInterval and clearInterval

Relationship between timer ID and cancellation

Difference between interval ID and callback function

Basic async timing patterns in JavaScript

Comprehensive and Detailed Explanation:

Errors thrown inside setTimeout callbacks occur asynchronously, in a different tick of the event loop. A try...catch around setTimeout itself (as in D) cannot catch errors thrown later in the scheduled callback.

To catch errors from countSheep() when it’s called asynchronously, the try...catch must wrap the call inside the timeout callback:

setTimeout(function() {

try {

countSheep();

} catch (e) {

handleError(e);

}

}, 1000);

B uses finally incorrectly and references e out of scope.

C is not valid JavaScript syntax.

D’s catch can only handle synchronous errors thrown before setTimeout returns, not those thrown inside the callback.

JSON.stringify(john) converts the john object into a JSON string.

When you JSON.parse that string back, you get a plain object :

Only data that can be represented in JSON is preserved (numbers, strings, booleans, arrays, plain objects).

Functions are not preserved and are dropped.

So dan is a plain object with properties firstName and lastName, but no name method .

Therefore, dan.name is undefined, and dan.name() throws:

TypeError: dan.name is not a function

The literal string interpolation inside console.log( ' Hello ${...} ' ) is also wrong (single quotes), but the code never reaches that line.

Comprehensive and Detailed Explanation:

Assuming SaleItem inherits from Item via prototype (e.g. SaleItem.prototype = Object.create(Item.prototype)):

Lines 01–02: create regItem and saleItem.

Line 03: define Item.prototype.description.

Now both regItem and saleItem (via inheritance) have a description method from Item.prototype.

Line 04: regItem.description() → ' This is a Scarf ' .

Line 05: saleItem.description() → ' This is a Shirt ' (same method, but this.name is ' Shirt ' ).

Line 07: SaleItem.prototype.description = ... overrides description only for SaleItem instances going forward.

If we imagine calling regItem.description() and saleItem.description() again after line 07:

regItem.description() still uses Item.prototype.description → ' This is a Scarf ' .

saleItem.description() now uses SaleItem.prototype.description → ' This is a discounted Shirt ' .

Those four lines correspond to option B.

From earlier pattern (cars/cats race):

One promise resolves the fastest with " Car 2 completed " (or analogous " Cat 2 completes " ).

Promise.race resolves with the first settled promise’s value.

In .then, value is " Car 2 completed " and:

let result = `${value} the race.`;

// " Car 2 completed the race. "

Thus result is " Car 2 completed the race. " → option A.

The key line is:

for (let something of obj) {

In JavaScript:

for...of is used to iterate over iterable objects, such as:

Arrays

Strings

Maps

Sets

Other objects that implement a [Symbol.iterator] method.

Plain JavaScript objects created with object literal {} are not iterable by default . They do not have [Symbol.iterator], so using for...of directly on them causes a runtime error.

Specifically:

for (let something of obj) { ... }

will throw a TypeError similar to:

obj is not iterable

Therefore, the loop body never executes, and console.log(output); is never reached without an error.

Why other options are incorrect:

B. [1, 2]

To get [1, 2], you could use Object.values(obj) and iterate that array.

But here, for...of obj never yields values because it throws an error.

C. [ " foo " , " bar " ]

To get property names, you could use Object.keys(obj) with for...of.

Again, the code does not do that; it incorrectly tries to iterate the object directly.

D. [ " foo:1 " , " bar:2 " ]

You would need both keys and values, combining them manually.

The given code does not implement such logic and fails before pushing anything into output.

Hence, the correct answer is:

Answer: A

Study Guide / Concept References (no links):

Difference between for...of and for...in

Iterables in JavaScript and [Symbol.iterator]

Plain objects {} are not iterable by default

Correct patterns to iterate object keys/values (Object.keys, Object.values, Object.entries)

Behavior of non-strict global code The script does not begin with a ' use strict ' directive at the top level, so the global code (outside any function) runs in non-strict (sloppy) mode.

Line 01: x = 3.14; In non-strict mode, assigning to an undeclared identifier (no var, let, or const) creates an implicit global variable. So after line 01, x exists and equals 3.14.

Line 08: z = x; This also runs in non-strict mode. Since x is already defined (from line 01), z is set to 3.14. Therefore, statement B is correct: z is equal to 3.14.

Scope of ' use strict ' inside a function The line:

' use strict ' ;

inside myFunction is a directive prologue for that function, not for the entire file. This means:

Strict mode applies only within the body of myFunction , from the directive to the end of that function.

It does not retroactively affect code before the function or code outside of it.

Therefore:

Statement A is incorrect: ' use strict ' is not “hoisted” to affect the whole file. It only affects the function body.

Statement C is incorrect: strict mode does not apply from line 04 to the end of the file; it only applies within myFunction, not to global lines like 01, 08, or 09.

Execution of myFunction in strict mode When myFunction is called on line 09:

function myFunction() {

' use strict ' ;

y = x;

}

Within this function:

Strict mode is active for its body.

In strict mode, assigning to an undeclared variable (like y here) is not allowed and results in a ReferenceError at runtime.

So line 05:

y = x;

throws a ReferenceError because y is not declared with var, let, or const.

Therefore, statement E is correct: line 05 throws an error.

Why statement D is considered correct Statement D says: ' use strict ' has an effect only on line 05.

In terms of execution in this specific code:

The only executable statement in myFunction that is affected by strict mode is the assignment on line 05.

The directive itself on line 04 is not a “normal” runtime operation; it is a directive that sets the mode.

There are no other statements inside the function that behave differently under strict mode; only the line that assigns to the undeclared variable shows a strict-mode effect.

So, describing the practical execution behavior of this snippet, strict mode manifests its effect only on line 05, making statement D correct in this context.

Summary of each option:

A: Incorrect – strict does not apply to all lines in the file.

B: Correct – z becomes 3.14 in non-strict global code.

C: Incorrect – strict does not affect code outside the function.

D: Correct – in this code, the only behavioral effect of strict mode is on line 05.

E: Correct – line 05 throws a ReferenceError due to assignment to undeclared y under strict mode.

JavaScript knowledge references (descriptive, no links):

In non-strict (sloppy) mode, assigning to an undeclared identifier creates a global variable.

' use strict ' inside a function body enables strict mode for that function only.

In strict mode, assigning to an undeclared variable results in a ReferenceError.

Directive prologues ( ' use strict ' ) affect only their containing function or script, not other scopes.

==================================================

The correct answer is B because countsDeep() is executed inside the callback function passed to setTimeout(), and the try...catch block is also placed inside that same callback.

In JavaScript, setTimeout() schedules a function to run later. The outer code finishes first, and the callback runs asynchronously after the delay. Because of this, a try...catch block placed outside setTimeout() cannot catch errors thrown later inside the callback.

Correct logic:

setTimeout(function() {

try {

countsDeep();

} catch (e) {

handleError(e);

}

}, 1000);

Here, when countsDeep() runs after 1000 milliseconds, any error thrown by countsDeep() happens inside the try block. Therefore, the catch (e) block can catch that error and pass it to handleError(e).

Why the other options are incorrect:

A is incorrect because the syntax is invalid JavaScript. A valid try...catch structure must be:

try {

// code

} catch (e) {

// handle error

}

Option A incorrectly writes:

} handleError (e){

catch(e);

}

That is not valid try...catch syntax.

C is incorrect because the try...catch surrounds only the call to setTimeout(), not the later execution of countsDeep(). If countsDeep() throws an error after the timer expires, the outer catch block will not catch it.

D is incorrect for the same reason as C. In the original question, D also had a typing error: it used countSheep() instead of countsDeep(). Even after correcting that typing error, D is still incorrect because the try...catch is outside the asynchronous callback.

The verified answer is C .

This object has two properties:

let obj = {

foo: 1,

bar: 2

};

The property names are:

foo

bar

The property values are:

1

2

The loop used here is a for...in loop:

for (let something in obj) {

output.push(something);

}

A for...in loop iterates over the property keys of an object, not the property values.

So during the first iteration:

something === " foo "

The code pushes " foo " into the array.

During the second iteration:

something === " bar "

The code pushes " bar " into the array.

The final value of output is:

[ " foo " , " bar " ]

That is why:

console.log(output);

prints:

[ " foo " , " bar " ]

Option B would be correct only if the code pushed the values, for example:

output.push(obj[something]);

Option D would require building formatted strings manually, such as:

output.push(`${something}:${obj[something]}`);

But the given code only pushes the property names.

Therefore, the verified answer is C .