Free Salesforce JavaScript-Developer-I Practice Exam with Questions & Answers | Set: 4

Behavior of Promise.prototype.finally:

.finally(handler) registers a callback that runs when the promise is settled , meaning:

Either fulfilled (resolved) , or

rejected .

Important points:

The finally callback does not receive the promise’s value or error (unlike then and catch).

It is executed after the promise is settled, but before the resolution value or rejection reason is passed further down the chain.

It runs in both success and failure paths.

In the given code:

The promise may either:

Call reject( ' fraction > 0.5, ' + fraction) if fraction > 0.5, or

Call resolve(fraction) otherwise.

In both cases:

If it resolves , .then(() = > console.log( ' resolved ' )) runs, and then .finally(...) is executed.

If it rejects , .catch((error) = > console.error(error)) runs, and then .finally(...) is executed.

So .finally runs:

Not just “when rejected”.

Not just “when resolved”.

But whenever the promise is resolved or rejected .

Therefore, the correct choice is:

D. When resolved or rejected .

Current behavior:

Clicking < td > triggers the click event on row1, then bubbles up to < table > .

printMessage runs, logs " Row log " , then event.stopPropagation() stops the event from bubbling to the table.

So " Table log " never appears.

To allow the table’s inline onclick to run after the row handler:

Remove the propagation stop:

function printMessage(event) {

console.log( ' Row log ' );

// event.stopPropagation(); // remove this

}

Now the event bubbles:

printMessage logs " Row log " .

The table’s onclick runs, logging " Table log " .

Option A only changes capture/bubble phase but still stops propagation. C does nothing meaningful (stopPropagation takes no arguments). B removes the row handler entirely.

ES Modules follow these rules:

Default exports are imported using:

import anyName from ' module '

The name chosen in the import does NOT need to match the exported name.

If a module exports:

export default function printDate() {}

then consuming code should import the function directly:

import printDate from ' /path/DatePrettyPrint.js ' ;

To execute it:

printDate();

Option analysis:

A incorrect: import DatePrettyPrint() is invalid syntax. Also calling printDate() without importing it is incorrect.

B incorrect: A default export imported as DatePrettyPrint gives the function itself, not an object containing methods. You cannot call DatePrettyPrint.printDate().

C incorrect: Imports printDate but then calls DatePrettyPrint.printDate(), which does not exist.

D correct: Correct import of a default-exported function. Correct direct invocation.

JavaScript Knowledge References (text-only)

Default export → imported without braces.

Importing default functions gives a callable function, not an object.

Correct syntax: import identifier from " module " .

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

This question tests understanding of let (block scope) and var (function scope) in JavaScript.

Initial declarations in the function:

let x = 1; // line 2

var y = 1; // line 3

Here:

x is declared with let, so it is block-scoped to the function body.

y is declared with var, so it is function-scoped to the entire function.

Inside the if (reassign) block (and since reassign is true, we enter it):

if (reassign) {

let x = 2; // line 6

var y = 2; // line 7

console.log(x); // line 8

console.log(y); // line 9

}

Detailed behavior:

let x = 2; on line 6 creates a new block-scoped variable x that exists only inside the if block. It does not change the outer x declared on line 2.

var y = 2; on line 7 declares y with var again, but var is function-scoped. This effectively reassigns the same y defined on line 3 for the entire function. After this line, y is 2 everywhere in the function.

Now, inside the if block:

console.log(x); (line 8) logs the inner block-scoped x, which is 2.

console.log(y); (line 9) logs y, which is the function-scoped y that was set to 2.

So the first two outputs are:

2

2

After the if block, execution continues:

console.log(x); // line 12

console.log(y); // line 13

Outside the if block:

The block-scoped let x = 2; no longer exists; it was only visible inside the if block.

The outer let x = 1; (line 2) is still in scope and has not been changed.

Thus:

console.log(x); (line 12) logs the outer x, which is still 1.

console.log(y); (line 13) logs y which, due to var y = 2; inside the if, is now 2 for the whole function.

Therefore, when myFunction(true) is called, the output in order is:

2 (inner x in if)

2 (function-scoped y after reassignment)

1 (outer x after if)

2 (function-scoped y remains 2)

This corresponds to:

Answer: B (2 2 1 2)

JavaScript knowledge / study guide reference concepts:

let declarations and block scope

var declarations and function scope

Shadowing of variables with let inside a block

Re-declaration and reassignment of var within a function

Execution order of statements and console output

The correct answer is C .

The browser provides the History API through:

window.history

To add a new entry to the browser’s session history without refreshing the page, JavaScript uses:

window.history.pushState(state, title, url);

So the valid statement is:

window.history.pushState(newStateObject, ' ' , null);

This updates the browser history stack without forcing a full page reload. It is commonly used in single-page applications when changing views or routes dynamically.

The method accepts three arguments:

window.history.pushState(stateObject, title, url);

stateObject stores custom data associated with the history entry.

title is usually passed as an empty string because many browsers ignore it.

url optionally changes the displayed URL. Passing null means no new URL is provided.

Option A is incorrect because:

window.customHistory

is not the standard browser History API object.

Option B is incorrect because:

createState()

is not a valid History API method.

Option D is incorrect because:

updateState()

is not a valid History API method.

The correct browser API method is:

window.history.pushState()

Therefore, the verified answer is C .

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)

The correct answer is D , because JavaScript executes synchronous code first, while the code after await runs later after the Promise resolves.

The execution order is:

console.log(2);

This runs first, so JavaScript logs:

2

Then this line runs:

asyncCall();

The asyncCall() function starts executing. Inside it, JavaScript reaches:

await delay(1000);

The delay(1000) function returns a Promise that resolves after 1000 milliseconds:

return new Promise(resolve = > {

setTimeout(resolve, delay);

});

Because await pauses the rest of the asyncCall() function, this line does not run immediately:

console.log(1);

Instead, JavaScript continues executing the remaining synchronous code outside the async function:

console.log(3);

So JavaScript logs:

3

After approximately 1000 milliseconds, the Promise returned by delay(1000) resolves. Then the paused async function continues and runs:

console.log(1);

So JavaScript logs:

1

Final console output:

2

3

1

Important JavaScript concepts involved:

An async function always returns a Promise.

The await keyword pauses execution only inside the async function where it appears.

Code outside the async function continues running normally.

setTimeout() schedules its callback to run later, after the current synchronous code has finished.

Therefore, the verified answer is D. 2 3 1 .

Synchronous execution order JavaScript executes code in a single thread, following a well-defined order:

All synchronous code runs first, line by line.

Asynchronous callbacks (like those scheduled with setInterval or setTimeout) are placed into the event queue and executed only after the current call stack is empty.

Let’s follow the code step by step:

Line 01:

let total = 10;

total is initialized with the value 10.

Line 02:

const interval = setInterval(() = > {

total++;

clearInterval(interval);

total++;

}, 0);

setInterval schedules the callback function to run repeatedly after a delay of at least 0 milliseconds, but it does not run immediately. The callback is added to the timer queue and will be invoked after the current synchronous script finishes and the event loop gets to process timer callbacks.

At this point, interval holds the interval ID, but the callback has not executed yet.

Line 07:

total++;

This is still synchronous, so it runs before any scheduled callbacks.

total was 10, now it becomes 11.

Line 08:

console.log(total);

At this moment, the interval callback has still not run (because the event loop has not yet processed the timer queue).

So total is 11, and console.log(total); outputs 11.

Therefore, the value printed at line 08 is 11, making option A correct.

What happens after the log (for understanding, not affecting the answer) After the main script finishes, the event loop processes the timer callback for setInterval:

Callback:

() = > {

total++; // from 11 to 12

clearInterval(interval); // cancels further executions

total++; // from 12 to 13

}

So eventually total becomes 13, but this happens after console.log(total) has already executed. Since the question asks specifically for the output at line 08, the asynchronous updates do not change that line’s output.

Why other options are incorrect

Option B (12): This would require the callback to run before the log, which does not happen because asynchronous callbacks are queued and executed after the current stack finishes.

Option C (10): Ignores the total++ on line 07.

Option D (13): This is the final value after the callback finishes, but it occurs after the console.log line executes, not at the time line 08 runs.

JavaScript knowledge references (descriptive, no links):

JavaScript is single-threaded and uses an event loop with a call stack and task queues.

setInterval schedules callbacks to run asynchronously after a minimum delay; the callback never runs before the current synchronous code finishes.

Synchronous statements like total++ on line 07 execute before any queued interval callback.

The correct answers are B, C, D, and E .

JavaScript browser consoles support string substitution in several console output methods. String substitution means using placeholders such as:

%s

%d

%i

%f

%o

%O

%c

Example:

console.log( " User name is %s and age is %d " , " Alex " , 25);

Output:

User name is Alex and age is 25

The valid console methods from the given options are:

Option

Method

Correct?

Reason

A

message

No

console.message() is not a standard console method.

B

log

Yes

console.log() supports formatted string substitution.

C

assert

Yes

console.assert() can output a formatted message when the assertion is false.

D

info

Yes

console.info() supports formatted output like console.log().

E

error

Yes

console.error() supports formatted output and displays an error-style message.

Example with these valid methods:

console.log( " Name: %s " , " John " );

console.info( " Score: %d " , 95);

console.error( " Error code: %d " , 500);

console.assert(false, " Failed check for user: %s " , " Admin " );

So the verified answers are B, C, D, and E .

Execution order:

Top-level code runs synchronously:

Line 14: console.log(4); → logs 4.

Line 15: callDelay(); is called.

Inside callDelay:

Line 9: console.log(2); → logs 2.

Line 10: await delay(1000);:

Calls delay(1000).

Inside delay(1000):

Line 3: console.log(1); → logs 1.

Line 4: setTimeout(resolve, delay); schedules resolve in 1000 ms.

delay returns a pending Promise. await pauses callDelay here and returns control to the event loop.

Back to top-level:

Line 16: console.log(5); → logs 5.

So synchronous log sequence is: 4, 2, 1, 5.

After ~1000 ms:

The setTimeout in delay resolves the Promise.

The await in callDelay resumes.

Line 11: console.log(3); → logs 3.

Final log order: 4 2 1 5 3.

Both A and B show the same sequence; one must be chosen, so A is correct.

Concepts: async/await flow, Promise resolution timing, event loop, and ordering of synchronous vs timer callbacks.