Issue type:

• 🐛 Bug

Short description:

When a displayed division variable gets into a division by 0 state it stays there even when it's denominator variable changes to non-zero

Expected behaviour:

The error should clear and the correct result of the division should be shown

Actual behaviour:

The error does not clear and the result of the division is not shown.

Steps to reproduce the problem:

1. Create a network with a variable store

2. Add an entity reader with an item frame on it and a block in the frame

3. Add a world reader and get the 'time until next rain aspect from it'

4. Get the 'item frame rotation' aspect from the entity reader

5. Create a variable in the logic programmer that divides the 'time until next' rain variable by the 'item frame rotation' variable.

6. Rotate the item in the item frame once (sets the rotation to 1).

7. Put the 'time until next rain' variable and the 'item frame rotation' variable in the variable store.

8. Add a display to the network and put the variable that does the division in it:
   

9. Click the item in the item frame to rotate it. The number in the display should change as you divide it by different numbers.

10. When you hit the rotation of 0 an error will show up in the display.
    

11. Clicking the item in the item frame again should clear the error (as the rotation transitions from 0 to 1), but it does not. To clear the error you have to remove the variable from the display and put it back again.
    

Versions:

• This mod: 1.12.2-0.11.5
• CyclopsCore: 0.11.4-799
• Minecraft: 1.12.2
• Forge: 14.23.1.2601

Log file:

No log as there was no crash

This is a consequence of how errors in ID work. For efficiency-reasons, errors will stop all further evaluation until someone resets the variable.

I recently tried to add transient errors in a separate branch in an attempt to make some errors not do this. I have no idea if or when I'll continue with this.

Perhaps it would be enough just to add something to the tooltip so that the player knows that their intervention is required in this case?
I thought I'd found a bug because most of the errors I see are due to missing variables or parts and they get automatically cleared when you remedy the problem.

Perhaps it would be enough just to add something to the tooltip so that the player knows that their intervention is required in this case?

Maybe. IMO it's pretty straightforward that this is required though.

Just for the record, errors due to missing variables that will clear automatically aren't visual distinguished from 'hard' errors that won't clear automatically:

Perhaps the 'hard' errors could be prefixed with some stronger text, such as 'Unrecoverable Errors:' instead of just 'Errors:'. Perhaps 'Unrecoverable' is too strong a term though... maybe 'Hard Errors:', and perhaps a short section in the book to distinguish them?

That was exactly the intention of the transient errors I mentioned before. At the moment, this distinction simply does not exist. All errors are simply reset when a variable reset event is emitted.

Got it -- I didn't pick up on the fact that you have to do something like interact with a variable containing inventory or change a part in the network for the other kinds of errors to get cleared and reevaluated.
I wonder if the LazyExpression functionality could also clear errors?
In the case I document above, I think that would mean that the division operator state (including its error state) would be cleared by invalidation when the item frame rotation changes...
I might just fire up the debugger and poke around for a bit.

Perhaps.

Have a look at that branch in any case, there are some todo's in there that complicate things regarding performance.

So, I didn't get anywhere with the LazyExpression poking around, but I did verify that making the EvaluationException("Division by zero") thrown by ValueTypeCategoryNumber#divide into a transient error on the feature-transient-errors branch was enough to fix the problem.
Are there any other issues that the feature-transient-errors branch is intended to address? I'm just looking for additional cases to test and hopefully reproduce the performance problem mentioned in the TODOs.

Are there any other issues that the feature-transient-errors branch is intended to address?

Nope, this (re-evaluting failed operators) was the only goal of that branch. You could for example also test out-of-bounds list retrievals, they should also throw a transient error.