Traps and Commit Points - throw confusion

Hey,

Actors and async data :: Internet Computer says that the points at which tentative state changes and message sends are irrevocably committed are:

  • await, return ,… but also throw
    Why is state not reverted after a throw statement? If division by zero happens or an assert fails then the state is also reverted, right? BUt why not through throw statement?
    Is it possible to catch the thrown error in the local canister? In this case state revert make no sense, but if the thrown error is not catched in the local canister then the state should be reverted, why is it not the case?

Thanks

1 Like

This is the explicit throw of Motoko, which maps to issuing a “reject” on the system level. On the system level, calls have either a reply or a reject as their response.

Don’t confuse throw (aka reject) with the concept of a trap, which happens when you divide by zero. That is not catchable within WebAssembly. Mildly confusing, it often appears that a trap causes a reject, but that is not always the case, and in some sense a trap in the canister causes a the system to response with a reject on the canister’s behalf.

1 Like

Isn’t “reject” not something that tells the caller that something went bad on the calling-side? In this case the caller knows his call failed and can assume that it didn’t lead to some state changes on the calling side. I don’t know, to me is an trap and an uncaught exception conceptually the same. For example in Java JPA, if an uncaught exceptions occurres inside a transaction then the transaction fails and the state will be reverted thats why it looks a bit weird that an uncaught exception through a throw sends a reject but don’t revert its state to last commit point.

it often appears that a trap causes a reject, but that is not always the case

In which cases can a trap not lead to a reject if it is uncatchable?

1 Like