6.4 Response checking

We have learned that the response of a public function determines whether a state change occurs on the chain. This applies not only to the initial contract call but also to subsequent calls. If a principal calls Contract A, which then calls Contract B, any changes made to Contract B's data members will be reverted if Contract B returns an error. However, Contract A can still modify its own data members and have those changes take effect if it returns a success. It is important to note that the first contract in the call retains ultimate control. If the function returns an error, any subsequent actions will not occur.

Therefore, committing or reverting changes must be done sequentially.

This means that in a chain of multiple contract calls, the calling contract can be certain that a sub-call will not occur on-chain if it returns an error response. However, a contract may still depend on the success of the sub-contract call. For instance, a wallet contract may call a token contract to transfer a token. Developers often forget to check the return value, which can lead to mistakes. To prevent this, BigBang requires all intermediary responses to be checked. An intermediary response is a response that is part of an expression but not the one that is returned.