These are just a few simple logging utilities provided to simplify and standardize the error facilities across the Ethers library.
TheLogger library has zero dependencies and is intentionally very light so it can be easily included in each library.
TheCensorship functionality relies on one instance of the Ethers library being included. In large bundled packages or whennpm link is used, this may not be the case. If you require this functionality, ensure that your bundling is configured properly.
Create a new logger which will includeversion in all errors thrown.
Log debugging information.
Log generic information.
Log warnings.
These functions honor the currentCensorship and help create a standard error model for detecting and processing errors within Ethers.
Create an Error object withmessage and an optionalcode and additionalparams set. This is useful when an error is needed to be rejected instead of thrown.
Throw an Error withmessage and an optionalcode and additionalparams set.
Throw anINVALID_ARGUMENT Error withname andvalue.
There can be used to ensure various properties and actions are safe.
Iftarget iskind, throws aUNSUPPORTED_OPERATION error otherwise performs the same operations ascheckNew.
This is useful for ensuring abstract classes are not being instantiated.
Ifcount is not equal toexpectedCount, throws aMISSING_ARGUMENT orUNEXPECTED_ARGUMENT error.
Iftarget is not a validthis ortarget value, throw aMISSING_NEW error. This is useful to ensure callers of a Class are usingnew.
Check that the environment has a correctly functioningString.normalize. If not, aUNSUPPORTED_OPERATION error is thrown.
Ifvalue is not safe as aJavaScript number, throws aNUMERIC_FAULT error.
Set error censorship, optionally preventing errors from being uncensored.
In production applications, this prevents any error from leaking information by masking the message and values of errors.
This can impact debugging, making it substantially more difficult.
Set the log level, to suppress logging output below aparticular log level.
Every error in Ethers has acode value, which is a string that will match one of the following error codes.
The operation is not implemented. This may occur when calling a method on a sub-class that has not fully implemented its abstract superclass.
There was an error communicating with a server.
This may occur for a number of reasons, for example:
The operation is not supported.
This can happen for a variety reasons, for example:
The amount of data needed is more than the amount of data required, which would cause the data buffer to read past its end.
This can occur if a contract erroneously returns invalid ABI-encoded data or RLP data is malformed.
There was an invalid operation done on numeric values.
Common cases of this occur when there isoverflow,arithmetic underflow in fixed numeric types or division by zero.
The type or value of an argument is invalid. This will generally also include thename andvalue of the argument. Any function which accepts sensitive data (such as a private key) will include the string"[[REDACTED]]" instead of the value passed in.
An attempt to call a blockchain contract (getter) resulted in a revert or other error, such as insufficient gas (out-of-gas) or an invalid opcode. This can also occur during gas estimation or if waiting for aTransactionReceipt which failed during execution.
Consult the contract to determine the cause, such as a failed condition in arequire statement. Thereason property may provide more context for the cause of this error.
The account is attempting to make a transaction which costs more than is available.
A sending account must have enough ether to pay for the value, the gas limit (at the gas price) as well as the intrinsic cost of data. The intrinsic cost of data is 4 gas for each zero byte and 68 gas for each non-zero byte, as well as 35000 gas if a transaction contains noto property and is therefore expected to create a new account.
When replacing a transaction, by using a nonce which has already been sent to the network, but which has not been mined yet the new transaction must specify a higher gas price.
This error occurs when the gas price is insufficient tobribe the transaction pool to prefer the new transaction over the old one. Generally, the new gas price should be about 50% + 1 wei more, so if a gas price of 10 gwei was used, the replacement should be 15.000000001 gwei. This is not enforced by the protocol, as it deals with unmined transactions, and can be configured by each node, however to ensure a transaction is propagated to a miner it is best practice to follow the defaults most nodes have enabled.
When a transaction has been replaced by the user, by broadcasting a new transaction with the same nonce as an existing in-flight (unmined) transaction in the mempool, this error will occur while waiting if the transaction being waited for has become invalidated by that other transaction.
This can happen for several reasons, but most commonly because the user has increased the gas price (which changes the transaction hash) to "speed up" a transaction or if a user has "cancelled" the transaction in their client. In either case this is usually accomplished by bribing the miners with a higher gas priced transaction.
This error will have the additional properties,cancelled,hash,reason,receipt andreplacement.
See theTransactionResponse for thewait method for more details.
When estimating the required amount of gas for a transaction, a node is queried for its best guess.
If a node is unable (or unwilling) to predict the cost, this error occurs.
The best remedy for this situation is to specify a gas limit in the transaction manually.
This error can also indicate that the transaction is expected to fail regardless, if for example an account with no tokens is attempting to send a token.
Log all output, including debugging information.
Only log output for informational, warnings and errors.
Only log output for warnings and errors.
Only log output for errors.
Do not output any logs.