You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The method called here returns a promise, but that promise is then dropped on the floor. When a failure occurs in the method, this results in an unhandled rejection error in node with a threat to crash the application in future versions of node. I have argued with the node/chrome maintainers at length that this is an incorrect behavior and inappropriate usage of promises but ultimately they decided to prefer making node "easy for bad programmers" rather than "powerful for advanced users" and it doesn't look like they plan on changing this. Because of this, all promises in a library should either return up the stack to the end-user or should be capped with a catch(...) before they are dropped.
Steps to reproduce
Instantiate a contract.
Call a method on that contract.
Have your Ethereum node return a failure like {"id":6604108303907,"jsonrpc":"2.0","result":"0x6864f52eba193e1b7d1b2eafddcf454dfb1568d756c5782d40efbc8c8857efbc","error":{"message":"VM Exception while processing transaction: invalid opcode","code":-32000}}
In my case, the error I get back looks like (though the error specifics shouldn't matter):
This whole problem would go away if the library used promises all the way down rather than just faking it half of the time and using callbacks the other half of the time. Also, if written in ES2017 you could use async/await which would make the code much easier to read.
The text was updated successfully, but these errors were encountered:
MicahZoltu
added a commit
to MicahZoltu/ethjs-contract
that referenced
this issue
Oct 6, 2017
Fixesethjs#10.
Rather than intermixing callbacks and promises, this opts to just use promises all the way through.
Giant caveat: This means that the `query` passed in to the constructor _must_ support promises. I personally think this is the right/sane thing to do, but if you want to continue to support callbacks you will need to solve this bug in a different way (e.g., swallow the promise result of `query[queryMethod](...)`).
Issue Type
Description
The method called here returns a promise, but that promise is then dropped on the floor. When a failure occurs in the method, this results in an unhandled rejection error in node with a threat to crash the application in future versions of node. I have argued with the node/chrome maintainers at length that this is an incorrect behavior and inappropriate usage of promises but ultimately they decided to prefer making node "easy for bad programmers" rather than "powerful for advanced users" and it doesn't look like they plan on changing this. Because of this, all promises in a library should either return up the stack to the end-user or should be capped with a
catch(...)
before they are dropped.Steps to reproduce
{"id":6604108303907,"jsonrpc":"2.0","result":"0x6864f52eba193e1b7d1b2eafddcf454dfb1568d756c5782d40efbc8c8857efbc","error":{"message":"VM Exception while processing transaction: invalid opcode","code":-32000}}
In my case, the error I get back looks like (though the error specifics shouldn't matter):
Versions
Peanut Gallery
This whole problem would go away if the library used promises all the way down rather than just faking it half of the time and using callbacks the other half of the time. Also, if written in ES2017 you could use async/await which would make the code much easier to read.
The text was updated successfully, but these errors were encountered: