Currently, the History contract raises panic code 0x32 when one provides an invalid claim index. This is because we are using Solidity arrays to store claims, and Solidity generates checks at compile time that raise such panic code if an index is outside the boundaries of an array.
From the user perspective, however, this panic code is often displayed with an error message (understandingly) too generic, which hinders the user experience.
Error: VM Exception while processing transaction: reverted with panic code 0x32 (Array accessed at an out-of-bounds or negative index)
at History.getClaim (contracts/history/History.sol:123)
at Authority.getClaim (contracts/consensus/authority/Authority.sol:100)
at CartesiDApp.getClaim (contracts/dapp/CartesiDApp.sol:199)
at CartesiDApp.executeVoucher (contracts/dapp/CartesiDApp.sol:114)
An experienced developer might be able to trace the error down to the exact file and line number, and then better diagnose the error from there. This, however, is not the case for most end users. :-)
✔️ Solution
One possible solution is to simply raise a more descriptive error when one provides an invalid claim index. This should give the end user or developer enough guidance to know what went wrong on a higher level.
Another solution is to expose a view function that allows one to check whether a claim exists or not. The idea is to call this function before actually retrieving the claim, provided that we guarantee that if the view function ensures that such a claim exists, then retrieving must succeed.
📚 Context
Currently, the
History
contract raises panic code 0x32 when one provides an invalid claim index. This is because we are using Solidity arrays to store claims, and Solidity generates checks at compile time that raise such panic code if an index is outside the boundaries of an array.From the user perspective, however, this panic code is often displayed with an error message (understandingly) too generic, which hinders the user experience.
An experienced developer might be able to trace the error down to the exact file and line number, and then better diagnose the error from there. This, however, is not the case for most end users. :-)
✔️ Solution
One possible solution is to simply raise a more descriptive error when one provides an invalid claim index. This should give the end user or developer enough guidance to know what went wrong on a higher level.
Another solution is to expose a view function that allows one to check whether a claim exists or not. The idea is to call this function before actually retrieving the claim, provided that we guarantee that if the view function ensures that such a claim exists, then retrieving must succeed.