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
When we have a revert in a transaction, webę throws an error, and the error message contains the revert reason, which is great. However, the message looks like Returned error: VM Exception while processing transaction: revert Name of storage is required -- Reason given: Name of storage is required.. Which means that we have to parse the message in order to get the revert reason, and the parser code is going to break every time the message formatting is changed (e.g. "Reason given" is changed to "Reason provided").
Would be great to have it structured, e.g. have a separate field that contains the revert reason. Or even something like this:
{
message: "Returned error: VM Exception while processing transaction: revert Name of storage
is required -- Reason given: Name of storage is required.",
inner: {
message: "VM Exception while processing transaction: revert",
status: "REVERT", //something that won't be changed or localized
inner: {
message: "Name of storage is required."
}
}
}
The reason (pun intended) is that we need to know 1) if the error was due to a revert and 2) if yes, what was the revert reason. This would be particularly helpful in automated tests, but also in UI.
The text was updated successfully, but these errors were encountered:
We have implemented this feature for 1.x and will release it on the next minor release. We will implement this feature also for 2.x and I'm closing this issue for now because we will anyways synchronize the existing features between 1.x and 2.x later.
When we have a revert in a transaction, webę throws an error, and the error message contains the revert reason, which is great. However, the message looks like
Returned error: VM Exception while processing transaction: revert Name of storage is required -- Reason given: Name of storage is required.
. Which means that we have to parse the message in order to get the revert reason, and the parser code is going to break every time the message formatting is changed (e.g. "Reason given" is changed to "Reason provided").Would be great to have it structured, e.g. have a separate field that contains the revert reason. Or even something like this:
The reason (pun intended) is that we need to know 1) if the error was due to a revert and 2) if yes, what was the revert reason. This would be particularly helpful in automated tests, but also in UI.
The text was updated successfully, but these errors were encountered: