Closed djMax closed 7 years ago
Can you provide the surrounding async/await usage, and `use strict' so I can try to reproduce the issue?
async function fn(customerSearchResults) {
const { body: responseBody, status } = customerSearchResults;
const { _embedded = {} } = responseBody;
const { customers = [] } = _embedded || {};
const [customer] = customers || [];
const { id: customerId } = customer || {};
console.log('The answer is', customerId);
}
fn({});
The following test actually works...
async function z() {
await Promise.resolve(0);
const customerSearchResults = {
body: {
_embedded: {
customers: [{
id: "a"
},{
id: "b"
}]
}
},
status: "status"
};
const {body: responseBody, status} = customerSearchResults;
const {_embedded = {}} = responseBody;
const {customers = []} = _embedded || {};
const [customer] = customers || [];
const {id: customerId} = customer || {};
return customerId === 'a';
}
z().then(log,$error);
But the transpiled code has a spurious declaration let undefined;
, which is clearly a bug and might be causing an error downstream
(that link goes to a 192.) I think that "let undefined" is really supposed to be "let _embedded" - it's missing a decl for that right? And since there's a use strict up top, boom.
My example doesn't seem to break it like the real code, so I'll see if I can make it fail fully.
Yep, you're right. I'll work out where I lost the identifier, hopefully an easier fix than your other issue in nodent
Boy I hoped the other one was easier. :) Unfortunately I think this isn't the last, because I worked around it by just not destructuring, but now there's some other problem (still diagnosing). THe background is we're trying to switch a big code base (lots of microservices) from async-to-generator to fast-async, so we're probably a pretty "wide" test case. But as long as your up for fixing 'em, we're up for finding 'em.
I live for fixing.
Here we go...
const c = { body: {}, status: 200 };
async function syncfn(customerSearchResults) {
const { body: responseBody, status } = customerSearchResults;
const { _embedded = {} } = responseBody;
const { customers = [] } = _embedded || {};
const [customer] = customers || [];
const { id: customerId } = customer || {};
console.log('The answer is', customerId);
}
async function getResults() {
await Promise.resolve(0);
return c;
}
async function asyncfn() {
const customerSearchResults = await getResults();
const { body: responseBody, status } = customerSearchResults;
const { _embedded = {} } = responseBody;
const { customers = [] } = _embedded || {};
const [customer] = customers || [];
const { id: customerId } = customer || {};
console.log('The answer is', customerId);
}
syncfn(c);
asyncfn(c);
Ah, and here's the other one I saw:
const c = { body: {}, status: 200 };
async function syncfn(customerSearchResults) {
const { body: responseBody, status } = customerSearchResults;
const { _embedded = {} } = responseBody;
const { customers = [] } = _embedded || {};
const [customer] = customers || [];
const { id: customerId } = customer || {};
console.log('The answer is', customerId);
}
async function getResults() {
await Promise.resolve(0);
return c;
}
async function asyncfn() {
let customerSearchResults;
try {
customerSearchResults = await getResults();
console.log('DONE');
} catch (error) {
console.log('EXCEPTION');
}
const { body: responseBody, status } = customerSearchResults;
const { _embedded = {} } = responseBody;
const { customers = [] } = _embedded || {};
const [customer] = customers || [];
const { id: customerId } = customer || {};
console.log('The answer is', customerId);
}
syncfn(c);
asyncfn(c);
Notice that BOTH "done" and "exception" are printed even though the exception (same as before) comes from AFTER the catch handler.
which, btw, is because of this:
try {
return Promise.resolve(getResults()).then(function ($await_3) {
try {
customerSearchResults = $await_3;
console.log('DONE');
return $Try_1_Post.call(this);
} catch ($boundEx) {
return $Try_1_Catch($boundEx);
}
}.bind(this), $Try_1_Catch);
} catch (error) {
$Try_1_Catch(error)
}
The $Try_1_Post should not be inside that larger try (I suppose instead it has to be in another try with a $Try_2_Catch that rejects the overall promise or something. Turns out this async/await thing is damn hard :)
Moved the latter case to nodent (and I'll move the former too). And yes, it gets fiddly around exceptions. Nodent has been in use for around 2 years, and these haven't turned up before, so you definitely get the 2017 prize (so far)
Both the above issue (and another one related to the order of assignments in declarations) are fixed by https://github.com/MatAtBread/nodent/releases/tag/3.0.14, which I'll publish to npm today.
Upstream fixes released in https://github.com/MatAtBread/nodent/releases/tag/3.0.14
I end up with an error saying _embedded is not defined (probably on line 3 there if the sourcemap is to be believed).
It transpiles to this:
Which doesn't look wrong, but somehow ends up failing, perhaps because of the 'use strict'?