In the past I had a private chat with you Khaled, about /reseterror. I was arguing that /reseterror wasn't so much needed as far as mIRC being in an error state was concerned.
To put it simply, I am under the assumption that once mIRC jumps to :error, it assumes that the rest of code can be 'safely' executed.
I was arguing that indeed, since we have to check for $error with an if statement somehow, at least if statement could be used.
It doesn't take long to someone curious to expand on this, and quickly one realizes that actually, the scripting engines just works, where practically speaking, /reseterror is really there to stop the display of the error (as far as the scripter is concerned anyway).
It makes perfect sense to me that the engine is able to keep processing the code, or at least that it could be made that way, quick tests does show that the scripting engine works fine and that my assumption is true... except for regex!
I believe I had shown this to you but you actually deleted our private conversation so I can't check:
this $regsubex cause the engine to leave the routine, the last echo is not echoed (it just return, it's not halting though), using $regex also reproduces the behavior, but pretty much any other feature works, so it's seems to be related to regex usage.

The reason that /reseterror is important is that there are a number of places where the scripting engine checks if it is in an error state and has to skip sections of code because of that. Regex, and some other identifiers, include a check for the error state. Many of these checks were added over time, when users reported issues, so they cannot be removed without re-introducing issues and changing the way the scripting language works. That is why it is recommended that /reseterror is called as soon as possible once an error is triggered, if you want a script to continue running normally. There is no way around this without a redesign of the scripting language I'm afraid.

Alright, thanks for the clarification.