SF-PD2 User Interface Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Use .then() to read the wrapper's success flag and conditionally fire the success toast, and .catch() to handle any Apex exception with an error toast.

  Why this is correct

  Imperative Apex calls return a Promise, so .then() receives the resolved wrapper, letting the developer check the success Boolean before showing the success toast. .catch() receives server-side Apex exceptions, enabling a distinct error toast. This separation correctly distinguishes a business-level failure (success false) from a runtime exception, satisfying the requirement that the toast appears only when the save truly succeeded.

• ✗

  Wrap the imperative call in a wire adapter and use the wired property's data and error values to drive the toasts.

  Why it's wrong here

  Wire adapters are for reactive, cacheable data reads, not for imperative save operations triggered by user action. A save must not run automatically when the component loads or when reactive parameters change, which is exactly what a wire adapter does. Using wire here would fire the save at unpredictable times and cannot be conditionally invoked from a button handler, so the pattern is fundamentally wrong for a save-then-toast flow.

• ✗

  Invoke the Apex method and use a setTimeout of 500 milliseconds before showing the toast, assuming the server will have responded by then.

  Why it's wrong here

  Timing the server response with setTimeout is unreliable; network latency or Apex processing time can exceed any fixed delay, and the toast could fire before or after the actual save completes. This approach also ignores the returned success flag and any exception, so failures would still show a success toast. It introduces a race condition rather than handling the asynchronous contract properly.

• ✗

  Call the Apex method inside a try/catch, and show the success toast in the try block right after the invocation line without inspecting the resolved value.

  Why it's wrong here

  An imperative Apex call returns a Promise; the code after the invocation line runs before the server responds. Showing the toast there means it appears regardless of the actual outcome, including when the save fails or the Apex method throws. The resolved value must be inspected inside .then() or after an await, so this pattern reports success prematurely and misleads the user.