简体   繁体   中英

Handle Promise Catches in Typescript

I have a promise based API service that requests data from my backend. It also comes with it's own error catch, so I don't have to write it everywhere. When it's written like this:

BackendService.ts

...
getTasks() {
    return axios.get('/api/tasks')
        .then((response) => {
            const {
                tasks
            }: {
                tasks: tasksType
            } = response.data;
            return tasks;
        })
        .catch((error) => console.log(error));
}
...

Entries.tsx

...
const getTasks = () => {
    backendService.getTasks()
        .then((tasks: tasksType) => {
            const filteredTasksData = filterAPIDataForState(tasks);

            addTasks({
                tasks: filteredTasksData
            });
        })
}
...

I get the following error:

TS2345: Argument of type '(tasks: tasksType) => void'
is not assignable to parameter of type '(value: void | tasksType) => void | PromiseLike<void>'.Types of parameters 'tasks'
and 'value'
are incompatible.Type 'void | tasksType'
is not assignable to type 'tasksType'.Type 'void'
is not assignable to type 'TaskInterface[]'.

I guess this is because of the catch, that could make the Promise return nothing (because of the console.log). If I give the getTasks from Entries.tsx it's own catch handler and remove it from BackendService.ts getTasks , it works.

Shouldn't Typescript be able to tell that the .then() in Entries.tsx would not run if there was an error, since there's already a catch handling this situation?

the.then() in Entries.tsx would not run if there was an error, since there's already a catch handling this situation?

That is not entirely correct.

catch block in getTasks method in backendService.ts file is returning undefined and when a catch block returns a value instead of throwing the caught error, instead of invoking catch block of the calling code, then block is invoked .

This happens because Promise returned by getTasks method in backendService.ts file depends on the following:

  • If the Promise returned by axios.get(...) fulfils then what you do in the then(...) block

  • If the Promise returned by axios.get(...) is rejected then what you do in the catch(...) block

In your case, if the Promise returned by axios.get(...) fulfils, then then(...) block will execute and since it just returns the tasks , Promise returned by getTasks method in backendService.ts file, fulfils leading to the invocation of then(...) block in the calling code, ie in Entries.tsx file.

If the Promise returned by axios.get(...) is rejected, catch(...) block will execute. Since catch(...) block in getTasks method is just logging the error, Promise returned by getTasks method will fulfil with the value of undefined which will lead to the invocation of then(...) block in the calling code , ie in Entries.tsx file.

See the following example to understand this.

 function getData() { // incorrect url which will lead to response.ok being false const url = 'https://jsonplaceholder.typicode.com/todo/1'; return fetch(url).then(response => { if (response.ok) { return response.json(); } else { throw new Error(); } }).catch(error => console.log('catch block in getData function')); } getData().then(data => console.log('then block ran')).catch(error => console.log('error block ran'));

In the above code snippet, as API URL is not correct, response.ok in the then block is false, so error is thrown from the then block which is caught by the catch block in the same function. As this catch block is just logging a message and returning undefined , Promise returned by getData function fulfils with the value of undefined . So instead of the catch block, then block executes in the code that calls getData function.

If you didn't know this then you might be surprised to see this behavior but that is how Promises work with catch blocks. The reason for this behavior is that if you have a promise chain that has more than one catch block, like shown below:

fetch(...)
  .then(...)
  .catch(...)   
  .then(...)
  .then(...)
  .catch(...);

then if the first catch block catches an error that is thrown from any of the functions chained before it, then this catch block can do one of the following two things:

  • throw the error which then will lead to the invocation of the last catch block
  • handle the error and return some value

if the first catch block returns normally, the promise returned by catch block fulfills with that return value of the catch block and this value then becomes the input of the callback function of the next then block in the promise chain. So the promise chain continues instead of stopping as soon as first catch block executes.


Coming back to your code, when catch block executes in the getTasks method in backendService.ts file, it logs the message and returns undefined which then leads to the invocation of then block in the Entries.tsx file, instead of the catch block and that is why you get a complaint from typescript about your code.

Solution

You can use one of the following options to solve this problem:

  • Throw the error caught in the catch(...) block of getTasks method in backendService.ts file so that Promise returned by getTasks method is rejected instead of fulfilling with the value of undefined .

  • Remove the catch block in the getTasks function in backendService.ts file and add the catch block in the code that calls getTasks method.

In my opinion, there's no need for a catch block in the backendService.ts file because if the Promise returned by axios.get(...) is rejected, Promise returned by getTasks method will also be rejected if there's no catch block in the getTasks method. So just remove the catch(...) block from the getTasks method and add the catch(...) block where you are calling this getTasks method.

There are many options to handle this

  1. In BackendService.getTasks() just remove.catch() and handle.catch() in the Entries.getTasks()
  2. In BackendService.getTasks() add another then and return with empty tasks for example.then(it => it || [])

Axios won't crash when response error so you must check response properly and handle it as it should be not just destruct response object blindly

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM