How can I call an async function from an event handler and surface its errors?

Keep the event decision, request, and UI cleanup as distinct steps. For a form, decide at the start whether its ordinary submission should be prevented. Then mark the interface busy, await the save, show success or an error, and restore the control in finally.

form.addEventListener("submit", async (event) => {
  event.preventDefault(); // Use if this handler replaces normal form submission.
  submitButton.disabled = true;
  status.textContent = "Saving…";

  try {
    await saveForm();
    status.textContent = "Saved.";
  } catch (error) {
    status.textContent = "Could not save. Please try again.";
    console.error("Save failed:", error);
  } finally {
    submitButton.disabled = false;
  }
});

Replace saveForm, form, submitButton, and status with your own function and elements. Promise catch() handles a rejection, while finally() runs after either fulfillment or rejection; an awaited operation can also be handled with try/catch/finally. [S1] [S2] The references establish those JavaScript handling and cleanup patterns, not the behavior of DOM events or a particular interface. The preventDefault() line is an event-specific choice: keep it if this handler should take over submission, and omit it if you want the form’s usual submission behavior.

Set the busy state immediately before starting the awaited work so the interface reflects the operation as soon as the handler reaches it. In this example, the status first says “Saving…” and the button is disabled; if saveForm() rejects, control moves to catch, where the status becomes a visible, user-friendly error. The finally block then restores the button on either outcome. [S2]

Keep the on-screen message useful without exposing internal details. If a failure needs investigation, logging the error can help during development, but don’t assume that a generic message tells the user whether the data was saved. That depends on what your save operation can establish.

Put the event decision at the beginning, before the asynchronous work, so it is visibly separate from success and failure handling. Use preventDefault() only when you intend this handler to replace the form’s ordinary submission; it is not an error-handling step. The supplied JavaScript references explain promise rejection handling and cleanup, but do not establish DOM event behavior, so confirm the event behavior you need in documentation for your environment.

Treat async as a way to write code that awaits work, not as a user-facing error message. Put the awaited operation inside the try and give catch an explicit response. The references support using try/catch for awaited failures and finally for cleanup. [S1] [S2]

The first example is the copyable version. Replace its placeholders with your own elements and operation: form is the form, submitButton is the control to disable, status is the visible message area, and saveForm() is the asynchronous work. Keep event.preventDefault() only if this handler should replace the form’s normal submission.

As you adapt it, check that you:

• show a busy state before awaiting the operation;
• provide an explicit success or failure message;
• use finally to restore the control after either outcome.

Choose a success message only when the awaited work completes successfully. Use catch for the rejection response and finally for cleanup. [S1] [S2]