The documentation refers to exceptions as a software architectural concept for use in (e.g.) checking array bounds. i.e., unexpected exceptions. The present way to handle such things in the MC-3020 is through marking, which is part of the architecture domain. Introducing architecture domain concepts into the action language is domain pollution.
Your example shows expected result handling for an event, which isn’t domain pollution, but as present mechanisms exist for handling expected failures, adding another adds complexity (richness and meaning???) to the action language. (I’m very glad OAL doesn’t already have the switch-case vs. if-else complexity.)
So…are the exceptions a replacement to current SW architecture mechanisms, or an addition to the OAL?