... it adds a bit of completeness to it all and it sort of surprises me that it's taken so long for me to use that particular instruction.
Also interesting to note that this code (for a Basic interpreter) checks overflow when things like BCPL, C, etc. don't check at all and just wrap... I wasn't going to bother until I found some code producing odd results and it was overflowing that was the cause.
I suspect that's why you've never bothered checking it until now - we are used to other languages that ignore overflows. e.g. do you ever check for unsigned overflow? I know I generally don't, unless the overflow is intended to happen.
One of the general principles of error handling is that you shouldn't check for errors if you don't have a way to handle them. In most languages, integer overflow isn't an error worth the implementation complexity of providing a handling mechanism. (In C, you even have to manually implement checks for null pointers!) In BASIC, being an interpreted language that can be interrupted just by the user pressing ESCAPE, it's relatively simple to just throw the usual sort of exception.
