Salesforce Certified JavaScript Developer JS-Dev-101 Exam Questions

Answer : D

Comprehensive and Detailed

The loop removes every 4:

Start: [1, 2, 3, 4, 4, 5, 4, 4]

i=0 1 (no change)

i=1 2 (no change)

i=2 3 (no change)

i=3 4 splice removes index 3 [1,2,3,4,5,4,4], then i-- 2

Next loop, i=3 4 again splice [1,2,3,5,4,4], i-- 2

i=3 5 (no change)

i=4 4 splice [1,2,3,5,4], i-- 3

i=4 4 splice [1,2,3,5], i-- 3

Next i=4, array.length is 4 loop ends.

All 4s removed, final array: [1, 2, 3, 5].

Answer : D

The correct answer is D.

Semantic versioning usually follows this format:

MAJOR.MINOR.PATCH

For the version:

1.1.3

The parts are:

1 = MAJOR

1 = MINOR

3 = PATCH

A package version should be updated based on the type of change:

MAJOR version changes when there are breaking changes.

MINOR version changes when new features are added in a backward-compatible way.

PATCH version changes when backward-compatible bug fixes are added.

The question says the developer added new features that do not break backward compatibility. That means the minor version should increase.

Starting version:

1.1.3

Increase the minor version from 1 to 2, and reset the patch version to 0:

1.2.0

Why the other options are incorrect:

A . 1.2.3 is incorrect because when the minor version increases, the patch version should reset to 0.

B . 1.1.4 is incorrect because that would represent a patch update, usually for bug fixes, not new features.

C . 2.0.0 is incorrect because that would represent a major version update, usually for breaking changes.

D . 1.2.0 is correct because it represents a backward-compatible feature release.

Therefore, the verified answe r is D.

Answer : C

console.assert(condition, message?) logs an assertion error if condition is falsy.

To log an error when number + 2 === 0 is false, use:

console.assert(number + 2 === 0);

Other options are invalid or do not behave as described: console.error always logs, assert alone is not a built-in browser global, and console.classy doesn't exist.

Answer : A

Object.preventExtensions(obj)

This built-in JavaScript method marks an object so that no new properties can be added to it.

Existing properties can still be read and updated, but adding new ones is disallowed.

const newObjBook = objBook;

Both variables reference the same object in memory. JavaScript objects are assigned by reference, not copied.

newObjBook.author = 'Robert';

Because the object has been marked as non-extensible, JavaScript will not allow new properties to be added.

The behavior depends on mode:

In non-strict mode: the assignment silently fails and does nothing.

In strict mode: this would throw a TypeError.

Since nothing indicates strict mode, this is non-strict behavior, making the assignment fail silently.

Therefore, the object remains:

{ title: 'JavaScript' }

Both objBook and newObjBook point to the same unchanged object.

This matches option A.

JavaScript knowledge references (text-only)

Object.preventExtensions() prevents adding new properties.

Assigning an object to another variable copies the reference, not the object.

Adding a property to a non-extensible object silently fails in non-strict mode.

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

Answer : B

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.

Answer : B

Initial values:

first = 'Who'

second = 'What'

Execution:

Inner try/catch/finally:

Line 05: throw new Error('Sad trombone');

Control goes to the inner catch.

Inner catch (lines 06--08):

catch (err) {

first = 'Why';

throw err;

}

first is set to 'Why'.

The error is rethrown.

Inner finally (lines 09--11):

finally {

second = 'When';

}

finally runs whether or not there was an error.

second becomes 'When'.

After inner finally, the rethrown error continues to propagate to the outer catch.

Outer catch (lines 12--14):

} catch (err) {

second = 'Where';

}

Because the inner try rethrew, the outer catch runs.

It sets second = 'Where'.

Final values:

first was changed to 'Why' in the inner catch and never changed again.

second became 'When' in the inner finally, and then 'Where' in the outer catch.

So:

first is 'Why'

second is 'Where'

Option B is correct.

Concepts: nested try/catch/finally, rethrowing errors, order of execution for catch vs finally, variable mutation through error propagation.

Answer : D

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.