Division by zero is a simple example of something that produces a "definitional error". It's considered to be "emitted" by the division, and if you try to "move on" without handling it, the raised error becomes a failure that you can only catch at some top level by SYS.UTIL.RESCUE.
For instance:
>> 1 / 0, 2 + 0
** Math Error: attempt to divide by zero
** Where: / console
** Near: [1 / 0 **, 2 + ***]
What happened was that 1 / 0 evaluated, but rather than forcing a "hard failure" (e.g. running FAIL) it instead returned a raised error. There's an opportunity if that raised error were to be intercepted, but in this case it just moseyed along to the next expression... so the raised error was promoted to a failure.
However a ^META oriented function can trap that, and react to it, allowing you to continue. EXCEPT is such a function:
>> 1 / 0 except e -> [print ["The error was" e.id]], 2 + 0
The error was zero-divide
== 2
One thing that pretty obviously shouldn't count as "moving on" would be parentheses. Adding parentheses shouldn't change the situation, they just pass any raised errors through:
>> (1 / 0) except e -> [print ["The error was" e.id]], 2 + 0
The error was zero-divide
== 2
>> ((((1 / 0)))) except e -> [print ["The error was" e.id]], 2 + 0
The error was zero-divide
== 2
But what about things like SET-WORD!s? Right now, it does not raise an error and just skips the assignment, and lets the code continue:
>> num: <before>
>> (num: 1 / 0) except e -> [print ["The error was" e.id]], 2 + 0
The error was zero-divide
== 2
>> num
== <before>
This is a useful pattern, but if we do it for SET-WORD!s then we have to ask whether it should be done for SET the function as well...
>> (set 'num 1 / 0) except e -> [print ["The error was" e.id]], 2 + 0
The error was zero-divide
== 2
If we do this then the SET function has to take its argument of the value to assign as a ^META argument. Because raised errors can't be stored in variables, and function parameters are communicated via variables.
This does make SET a more complicated function, and any functions like it might also become complicated. It's a hard decision to condemn all SET-like functions to take their arguments as ^META so they can proxy any errors and not perform the assignment.
I'll probably have more to say about this, but for the moment both SET and SET-WORD! react to definitional failures by not performing the assignment and propagating the raised error.