Can someone please explain why returning an Axios promise allows for further chaining, but returning after applying a then()/catch() method does not?
Example:
const url = 'https://58f58f38c9deb71200ceece2.mockapi.io/Mapss'
function createRequest1() {
const request = axios.get(url)
request
.then(result => console.log('(1) Inside result:', result))
.catch(error => console.error('(1) Inside error:', error))
return request
}
function createRequest2() {
const request = axios.get(url)
return request
.then(result => console.log('(2) Inside result:', result))
.catch(error => console.error('(2) Inside error:', error))
}
createRequest1()
.then(result => console.log('(1) Outside result:', result))
.catch(error => console.error('(1) Outside error:', error))
createRequest2()
.then(result => console.log('(2) Outside result:', result))
.catch(error => console.error('(2) Outside error:', error))
<script src="https://unpkg.com/axios#0.16.1/dist/axios.min.js"></script>
https://jsfiddle.net/nandastone/81zdvodv/1/
I understand that Promise methods should return a value to be chained, but why is there a difference between these two return methods?
Your first example returns the original promise. Your second example returns a different promise, the one created by calling catch.
The critical differences between the two are:
In your second example, you're not passing on the resolution value, so the promise returned by your then is resolved with undefined (the return value of console.log).
In your second example, you're converting rejections into resolutions with undefined (by returning the result of console.log out of catch). A catch handler that doesn't throw or return a promise that's rejected converts a rejection into a resolution.
One of the key things about promise chains is that they transform the result; every call to then or catch creates a new promise, and their handlers can modify what's sent downstream as the result passes through them.
The usual pattern would indeed be to return the result of the chain, but for the functions in the chain to either intentionally transform the result or pass it on. Normally, you wouldn't have a catch handler except at the terminal end of the chain, unless you're using it to correct the error condition (intentionally converting a rejection into a resolution).
If you wanted to just log what passed through while still allowing callers to see it but did want to return the result of the chain for whatever reason, you'd do this:
return request
.then(result => { console.log(result); return result; })
.catch(error => { console.error(error); return Promise.reject(error); });
or using throw:
return request
.then(result => { console.log(result); return result; })
.catch(error => { console.error(error); throw error; });
Related
I wanted to know why the promise below both call the catch() and then() method.
function testpromise(){
return new Promise((resolve, reject)=>{
reject("Error");
})
}
testpromise()
.catch((err)=>{console.log(err)})
.then(()=>{console.log("Then")})
But why this one doesn't ? (I only moved the .then() method before the .catch() one).
function testpromise(){
return new Promise((resolve, reject)=>{
reject("Error");
})
}
testpromise()
.then(()=>{console.log("Then")})
.catch((err)=>{console.log(err)})
Is this a bug ? It's kind weird that I can't get the catch() method before the .then(). For me putting catch before then allow me to quickly check if I handle possible errors correctly. I have dozens of promises wrote like so and I just noticed that it will also call my .then() method right away, which is not good.
A catch returns a promise so unless you throw or return another rejected promise it will resolve to the next then() in the chain
Following contrived example should help you visualize it
testpromise()
.catch((err) => {
console.log('First catch=', err)
return 'Catch message'; // implicit return value, with no return next then receives undefined
})
.then((fromCatch) => {
console.log("from first catch =", fromCatch)
})
.then(testpromise) // return another rejected promise to next catch
.then(() => console.log('Not called'))
.catch((err) => {
console.log('Second catch');
throw 'New Error'
})
.then(() => console.log('Not called #2'))
.then(() => console.log('Not called #3'))
.catch(err => console.log('Final catch =', err))
function testpromise() {
return new Promise((resolve, reject) => {
reject("Error");
})
}
Consider the following code:
try {
throw new Error("catch me if you can!");
} catch (err) {
// whatever
}
console.log("hi");
Because that is the synchronous equivalent of this:
Promise.reject(new Error("catch me if you can!"))
.catch(_ => { /* whatever */ })
.then(_ => console.log("hi"));
Each time you add a .then or .catch it returns a new promise, it doesn't modify the old one in place. So it's not that the order is wrong, it's that it matters. Otherwise you couldn't do something like this:
fetch(someURL)
.then(response => response.json())
.then(doSomethingWithJSON)
.catch(err => {
handleRequestFailure(err);
console.error(err);
return err;
})
.then(result => {
if (result instanceof Error) {
return fallbackRequest();
}
})
.catch(handleFallbackError);
A .catch() is really just a .then() without a slot for a callback function for the case when the promise is resolved.
MDN Promises Documentation
Think of the .then() function as a chain, each one does something according to the resolved value, and passes the returned value to the next .then() in the chain, or if an error thrown, to the .catch() method.
I want to call this api multiple times in my project and when I am calling it , It continues giving an error which is
TypeError: Failed to execute 'json' on 'Response': body stream already
read at main.js:Line number
My Code is as Follows
let thisIsUrl = 'https://api.covid19api.com/summary';
let a = fetch(thisIsUrl)
a.then((data) => {
return data.json()
}).then((apidata) => {
console.log(apidata)
return apidata
}).catch((error) => {
console.log(error)
})
a.then((fetchdata) => {
return fetchdata.json()
}).then((readingData) => {
console.log(readingData)
}).catch((err) => {
console.log(err)
})
You're not calling fetch multiple times. You're calling it once, and then trying to read the response body multiple times. That's why the error says you're trying to read the body when the stream is already closed — it was closed when you were done reading it the first time.
If you want to use the data twice, store it somewhere and use it twice.
let thisIsUrl = 'https://api.covid19api.com/summary';
let a = fetch(thisIsUrl)
a.then((data) => {
return data.json()
}).then((apidata) => {
// **************** Use it twice here
}).catch((error) => {
console.log(error)
})
If you want to fetch it again because it may have been updated, call fetch again:
let thisIsUrl = 'https://api.covid19api.com/summary';
fetch(thisIsUrl)
.then((data) => {
return data.json();
}).then((apidata) => {
console.log(apidata);
return apidata;
}).catch((error) => {
console.log(error);
});
// Presumably this is later (in time), not immediately after the above
fetch(thisIsUrl)
.then((fetchdata) => {
return fetchdata.json();
}).then((readingData) => {
console.log(readingData);
}).catch((err) => {
console.log(err);
});
Finally, this seems unlikely, but if you really want to fetch it once and use that one result in multiple places via the promise chain, keep the promise from then rather than the promise from fetch:
let thisIsUrl = 'https://api.covid19api.com/summary';
let a = fetch(thisIsUrl)
.then((data) => {
return data.json()
});
a.then((apidata) => {
// ***** Use it here
}).catch((error) => {
console.log(error)
})
a.then((readingData) => {
// ***** And then again here
}).catch((err) => {
console.log(err);
});
Side note: Your code is falling prey to a footgun in the fetch API; I've written about it in this blog post. fetch only rejects its promise on network errors, not HTTP errors. You have to check for those yourself in the first fulfillment handler, by checking for ok on the response object:
fetch("/your/resource")
.then(response => {
if (!response.ok) {
throw new Error("HTTP error " + response.status); // Or better, use an Error subclass
}
return response.json();
})
// ...
fetch returns Promise, generally, promises have something like state inside themself;
pending: initial state, neither fulfilled nor rejected.
fulfilled: meaning that the operation was completed successfully.
rejected: meaning that the operation failed.
(source)
So when we call them and get the value from them with then, catch and etc. then they change the state after that call. So here, when you read the value with a.then(…, the promise changes its state to fulfilled and you are not able to call it again, you need a new and fresh Promise, actually a new instance of the fetch.
I want to recommend you to use Promise.all().
let thisIsUrl = 'https://api.covid19api.com/summary';
let a = fetch(thisIsUrl)
.then((data) => {
return data.json()
}).then((apidata) => {
console.log(apidata)
return apidata
}).catch((error) => {
console.log(error)
})
Promise.all([a,a,a]);
.then(results => {
// Results are here.
});
I have my function handleRes who is exec in await.
But i want exec a function when the await is ended. Like with .then or .catch
How can i do something like this
I import this function
const handleRes = res => {
res
.then(({ data }) => {
console.log('done');
})
.catch((error) => {
console.log('error');
});
};
Read it in this file and exec something when it end
await handleRes(res).then(() => setLoading(false));
handleRes doesn't return the promise chain, so you can't wait on its work to finish from outside of it. The solution is to modify it so that it returns the chain:
const handleRes = res => {
return res
//^^^^^^
.then(({ data }) => {
console.log('done');
})
.catch((error) => {
console.log('error');
});
};
Then you can await it. In the normal case, that would like:
await handleRes(res);
setLoading(false);
...but your version using then also works.
In the normal case, you would also remove that error handler so that errors propagate along the chain and are handled by the functions calling handleRes (or the functions calling them, if they pass the chain along). With the function as shown above (with the catch), the caller has no way to know whether the operation succeeded or failed, because the catch converts the rejection into a fulfillment (with the value undefined).
I wrote a snippet of code that gets some a JSON from the Foursquare API. From this JSON, I get IDs of venues. These IDs are then used to get more details from those specific venues by issuing a fetch() request for every ID, and mapping those requests in an array. That array is then passed into Promise.all(). When the API is available, everything works, but it's the error catching that I can't get my head around.
fetch(`https://api.foursquare.com/v2/venues/search?${params}`)
.then(response => response.json())
.then(data => {
const venueIds = data.response.venues.map(venue => venue.id)
const venuePromises = venueIds.map(venueId => {
fetch(`https://api.foursquare.com/v2/venues/${venueId}?${otherParams}`)
.then(response => {
// Must check for response.ok, because
// catch() does not catch 429
if (response.ok) {
console.log('ok')
return response.json()
} else {
Promise.reject('Error when getting venue details')
}
})
})
Promise.all(venuePromises).then(data => {
const venues = data.map(entry => entry.response.venue) // Error for this line
this.parseFsqData(venues)
}).catch((e) => {console.log(e); getBackupData()})
}).catch((e) => {console.log(e); getBackupData()})
function getBackupData() {
console.log('backup')
}
When the API is not available, I get the following console errors (and more of the same):
TypeError: Cannot read property 'response' of undefined
at MapsApp.js:97
at Array.map (<anonymous>)
at MapsApp.js:97
backup
api.foursquare.com/v2/venues/4b7efa2ef964a520c90d30e3?client_id=ANDGBLDVCRISN1JNRWNLLTDNGTBNB2I4SZT4ZQYKPTY3PDNP&client_secret=QNVYZRG0JYJR3G45SP3RTOTQK0SLQSNTDCYXOBWUUYCGKPJX&v=20180323:1 Failed to load resource: the server responded with a status of 429 ()
Uncaught (in promise) Error when getting venue details
I don't understand why then() after Promise.all() is entered, because response is never ok (there is no ok logged in console). Also, I don't understand why the console.log()'s in the catch() blocks aren't executed, or why they are empty. I don't see any caught error information in console, but still the getBackupData function is called. Finally, it is unclear why the last message in console indicates that the error is uncaught, as I expected reject() to make Promise.all() fail.
How can I tactfully catch any errors (included those not normally caught by catch(), such as 429 errors) and call getBackupData when any errors occur?
Your issues are related: namely, the Promise chain must be returned. If you do not return the Promise, you disconnect any of the caller's Promise#catch handling, and any errors in your Promise / then code will result in unhandled promise rejection errors, such as what you have obtained:
Uncaught (in promise) Error when getting venue details
This uncaught promise rejection appears in your code that handles the resolution of fetch:
if (response.ok) {
console.log('ok')
return response.json()
} else {
Promise.reject('Error when getting venue details') // <----
}
Since this code is being used to construct your venuePromises array, its return value will populate venuePromises. If the response was ok, that array element will have the response JSON from return response.json(). If the response failed, there is no return statement that executes, so the array element has the value undefined. Thus, venuePromises would look like this:
[
{ /** some object for successful response */ },
undefined,
{ /** some other object */ },
...
]
Thus when this array is accessed by your Promise.all's success handler, you get the TypeError since you expected all elements of venuePromises to be valid. This TypeError is caught by the Promise.all's .catch handler (which is why it is logged, and you receive the "backup" text in your log).
To fix, you need to return the Promise.reject, and also the Promise.all. Note that there are some cases of implicit return, but I find it nicer to be explicit, especially if the statement spans multiple lines. Since you're returning the Promise.all statement, you can offload its .then and .catch to the caller, resulting in one less nesting level, and one fewer duplicated .catch handler.
fetch(`https://api.foursquare.com/v2/venues/search?${params}`)
.then(response => response.json())
.then(jsonData => {
const venueIds = jsonData.response.venues.map(venue => venue.id);
const venuePromises = venueIds.map(venueId => {
let link = `https://api.foursquare.com/v2/venues/${venueId}?${otherParams}`;
return fetch(link).then(response => {
// Must check for response.ok, because catch() does not catch 429
if (response.ok) {
console.log('ok');
return response.json();
} else {
console.log(`FAILED: ${link}`);
// Return a Promise
return Promise.reject(`Error when getting venue details for '${venueId}'`);
}
});
});
return Promise.all(venuePromises);
})
.then(venueData => {
const venues = venueData.map(entry => entry.response.venue);
this.parseFsqData(venues);
})
.catch(e => {console.log(e); getBackupData()});
function getBackupData() {
console.log('backup')
}
Try returning the rejected promise.
return Promise.reject('Error when getting venue details')
When working with promises you should return inner promises instad of working with inner "thens".
Check this:
fetch(`https://api.foursquare.com/v2/venues/search?${params}`)
.then(response => response.json())
.then(data => {
const venueIds = data.response.venues.map(venue => venue.id);
const venuePromises = venueIds.map(venueId => {
fetch(`https://api.foursquare.com/v2/venues/${venueId}?${otherParams}`)
.then(response => {
// Must check for response.ok, because
// catch() does not catch 429
if (response.ok) {
console.log('ok')
return response.json()
} else {
return Promise.reject('Error when getting venue details')
}
})
});
return Promise.all(venuePromises)
})
.then(venueValues => {
const venues = venueValues.map(entry => entry.response.venue); // Error for this line
this.parseFsqData(venues);
})
.catch((e) => {console.log(e); getBackupData()})
function getBackupData() {
console.log('backup')
}
When returning Promise.all as a value, you're returning a promise so that you can chain further "then" callbacks. The last catch shall capture all promise rejects.
You're also missing the return in the else clause
Hope this helps
I believe the solution is fairly simple; The response of the nested fetch method is missing a return statement. You should get rid of that mysterious error once it is in place.
const venuePromises = venueIds.map(venueId => {
<missing return statement here> fetch(`https://api.foursquare.com/v2/venues/${venueId}?${otherParams}`)
.then(response => {
Let's say I have a file that is importing a function from the api and doing something with the result.
import api from './api'
const getData = () => {
api.get(url)
.then(res => console.log(res))
.catch(err => console.log(err))
}
I've seen two different styles for returning the response so the error bubbles up.
version 1:
get: (url) => {
return new Promise((resolve, reject) => axios.get(url)
.then(res => resolve(res))
.catch(err => reject(err)) )
}
version 2:
get: (url) => {
return axios.get(url)
.then(res => {
if (res.success == 200) {
return Promise.resolve(res)
}
return Promise.reject(res)
})
}
What are the differences between the two approaches? Is there a preferred/better method for error handling?
In general, two handy rules:
If your starting point is a promise (the return value of axios.get), then using new Promise is an anti-pattern. then and catch already create new promises.
Propagate errors, don't convert them to resolutions (until, of course, the point at which your handling those errors, usually near the beginning of the call chain).
Based on that, of those two options, you'd use Version 2, not Version 1.
Version 1 is a bit nonsensical: It eats the resolution value and converts errors to resolutions; it will always resolve to undefined. Remember that the result of the chain is the result of the last thing returned (or thrown) in a then or catch handler. Those two handlers don't return or throw anything, so the chain resolves (rather than rejecting) with undefined.
Version 2 does something: It modifies the promise result based on res.success. But it doesn't need Promise.resolve, it should just be:
get: (url) => axios.get(url).then(res => {
if (res.success == 200) {
return res;
}
return Promise.reject(res); // Or see note below
})
And there's a camp — which I agree with — which says you should always throw an Error object rather than returning Promise.reject, for stack trace info. So:
get: (url) => axios.get(url).then(res => {
if (res.success == 200) {
return res;
}
throw new Error(res/*...or something else useful here...*/);
})
There is no real difference with the two versions, at the first one, you are creating a redundant Promise.
axios.get, is a function that returns a Promise there is no need to wrap it with another one.
You can warp with additional Promise if you wanna change the promise logic, meaning that if you wanna resolve no matter of what happened in axios promise.
Something like that:
get: (url) => {
return new Promise((resolve, reject) => axios.get(url)
.then(res => resolve(res))
.catch(err => resolve(err)) )
}
but, usually it is not the practice.