No, you don't always need to await a promise. But, to ensure proper application flow, you should always be ready to handle any error that occurs.
If you do not await a promise, you should implement the catch callback. So either the code as you wrote it in your question, or something along the lines of:
const specialFunction = () => {
handleEventInsertion(body)
.catch(error => {
logger.error(error);
});
}
You can choose to not do that, but as you've already stated: if an error occurs and you do not try/await/catch the promise or .catch the error, it will be regarded as an unhandled rejection.
Edit:
As for your other question: is there a scenario where you should not await on a promise?
Yes. If you're responding to a user action that needs to report back immediately after triggering something that may take a while, you want that to be handled asynchronously and you don't want to wait for it to finish. But, in that case the asynchronous function you're calling should handle the error. As an example:
const onClick = () => {
handleEventInsertion(body); // asynchronous function
alert("Thanks, we'll take it from here");
};
const handleEventInsertion = async (body) => {
try {
const result = await performLengthyAsyncOperation(body);
alert(`${result} inserted successfully`);
} catch (error) {
logger.error(error);
}
// or using the callbacks instead of try/await/catch:
performLengthyAsyncOperation(body)
.then(result => {
alert(`${result} inserted successfully`);
}).catch(error => {
logger.error(error);
});
};
Edit 2:
If you, for some reason, really don't want to use await at all, there is an alternative solution: you can trap the unhandled rejection errors.
window.onunhandledrejection = (error) => {
logger.error(error);
};
If you do that, you don't need to catch the error everywhere if the handling is always going to be same. In that case, you'd only await a promise if you need the result of the function or if a particular error requires special treatment.