1

For example I have an async function:

prepAttrsRef.current.addEventListener('documentstatechanged', async (evt: CustomEvent<FlowDocumentState>) => {
if (evt.detail.draftState === 'unpublished-changes') {
  dispatch(updateIsFlowpublished(false));
  await publishPrepFlow();
}
if (evt.detail.draftState === 'all-changes-published') {
     await cleanSteps[0].selectAsync();
  }
}
await getAndDispatchPrepColumns();
});

Should I always enclose the await lines with try/catch or at least a catch to handle the potential case that the promise could be rejected? (Although I don't know if the promise will be reject or not, since I am calling the API created by others)

lightrek
  • 951
  • 3
  • 14
  • 30
  • Yes, its a good practice. You should always try to add error handling scenarios for production ready apps – Kaneki21 Jul 10 '22 at 12:23
  • Using `try`/`catch` may be a good practice, but one should be aware that even in modern JavaScript runtimes it incurs a performance penalty. Of course, when a function is mostly waiting on external activity as in the OP here, that probably doesn't matter. – Pointy Jul 10 '22 at 12:39
  • NB: `await` is not a statement. It is an operator. – trincot Jul 10 '22 at 12:46
  • [Not always (or even: in most cases), no](https://stackoverflow.com/q/50896442/1048572). But in this case, in an event handler where you cannot return a promise to anyone else and basically end the chain: yes, you should handle the errors that might occur. – Bergi Jul 10 '22 at 14:58

2 Answers2

0

It is always a good practice to handle exceptions at the point of origin to avoid hours of debugging to find out why the code is breaking. Now, having said that I believe you need to decide at what level you need to handle exceptions.

In production, you have no idea what input/parameters you might get if those are exposed to the end-user. There might be a case where the input is some value that can't be handled by the underlying API which will cause your service to fail.

enter image description here

For example,

If you wrap the entire block of code i.e. two await statements in a try-catch block, you won't know which await failed unless you have custom exceptions raised by the awaited function.

Vishnudev Krishnadas
  • 10,679
  • 2
  • 23
  • 55
  • "*handle exceptions at the point of origin*" - that doesn't make sense. If you could immediately handle the exception right where it originated, the code wouldn't have to throw the exception in the first place. – Bergi Jul 10 '22 at 15:00
  • 1
    "*you won't know which `await` failed*" - that's what stack traces and error messages are used for. – Bergi Jul 10 '22 at 15:01
  • *"handle exceptions at the point of origin"* ~ I meant for external API calls, handle where the call takes place. *"you won't know which await failed"* ~ Stack trace will help only if the error is logged in the catch block. But it usually is a custom error message. Sorry if it wasn't clear. – Vishnudev Krishnadas Jul 10 '22 at 17:56
0

for clean code, yes, you should do that, your function supposed to do one thing and if it fails you should let it bark(where the problem), that will help you in debugging.

if you have many try/catch in the same block, your function does many things, and that's not good practice.

this is a good example

try{
await publishPrepFlow();
}catch(error){

// throw it to handle it on a different level
throw Error('unable to publishPrepflow')

// no any action | write on log file at least ...
console.log('unable to publishPrepflow')
}

to handle all uncaught Exception & Rejected Promises

process
  .on('unhandledRejection', (reason, p) => {
    console.error(reason, 'Unhandled Rejection at Promise', p);
  })
  .on('uncaughtException', err => {
    console.error(err, 'Uncaught Exception thrown '+ err.message);
  });
Hazem Hatem
  • 1
  • 1