Thanks to @islami00 for the question (not verbatim):
I have done all error checking as instructed here.
Am I now save toexpect
all futureResult
s even after modifying storage?
When is it permissible to use expect
?
What happens when it fails?
Substrate and Polkadot Stack Exchange is a question and answer site for developers building blockchains with the Substrate SDK. It only takes a minute to sign up.
Sign up to join this communityThanks to @islami00 for the question (not verbatim):
I have done all error checking as instructed here.
Am I now save toexpect
all futureResult
s even after modifying storage?
When is it permissible to use expect
?
What happens when it fails?
Short answer: never use expect
, unwrap
or other panickers in runtime code.
Long answer: only if you can prove that it will never panic, and you are confident that your code is so simple and maintainable that nobody could ever make a change which would result in that proof becoming broken and a panic possible.
In general, it's better to just not include anything which can panic since it will open you up to DoS attacks, or, if the panic happens during one of the runtime hooks (on_initialize
&c.) then your chain will halt.
When is it permissible to use expect?
When you can prove that it can not panic. Aka you have done all required checks, like that the data exists or that some kind of arithmetic operation will succeed.
What happens when it fails?
The block producer will throw away the transaction and any modifications to the state that have been done. The problem with this is that you can DoS the block producers for free. You can just send the same tx over and over again, you will not need to pay (because we revert all the state, this includes fee deduction if a tx panics), but the block producer will try to include it.
You use expect
where you want to communicate that unwrapping this result should never fail. You can use unwrap or unwrap_or where you aren't sure, but for infallible calls, you should use expect
.