Future request: An internal mIRC error handling event, e.g.:

on *:ierror:<matchtext>: do something

So remote scripts can trigger the internal error message(s) and can take action on this.
I think this is a serious option for mIRC.
_________________________________________
'n chillout

I see catching an error, but I don't see how to trigger an error (unless you're not suggesting user errors?). Are you suggesting /ierror to trigger an error?

Either way, I see a few problems with this. Namely, using a separate event to catch an error means you lose you're original location. Where did the error come from? What was my state when the error occurred? How can I go back? Without getting access to pre-error state, or being able to continue from that state, this event is pretty much only useful for theming an error message and nothing more.

Do you know about the :error label functionality? Although it's not perfect, it solves most of the error related problems (it even supports, to a minor degree, "user errors"). The important part is that you keep your state, and you can gracefully resume from an error using this method.

chillout___, type /help Error handling in mIRC and see if this is what you are looking for. (This is the :error thing that argv0 was alluding to.)

If it's not, can you give an example of what sort of error you want to intercept that can't be done through this method?

I'm pretty sure that this has been suggested a million times before, unless I'm not getting it right.

Thank you guys,

However, I am aware of the :error handling in the mirc help file, the point is that it doesn't trigger error messages like for example:


etc., those were only some examples.
Hope it is more clear what i mean and it is not already possible.

@Knoeki: Can you help me with a couple of links to the millions of requests? I couldn't find them.

Thanks all!

________________________________
'n chillout

I can't find them either right now, sorry. I'm sure things like this have been requested before, though.

the "something Unknown command" messages are sent from the server. You'd have to track down their raw nummerical number to stop those.

Same with LIST output too large and no such nick/channel. These can be handled with RAW events-- and specifically CANNOT be handled with any "ierror" event, because they are not "internal" errors. They are server errors.

WRRITE unknown command isn't server related, like *Unable to resolve server, forget about the list output and no such nick channel, those were only some examples. Please help me with a code to handle e.g.: *Unable to resolve server, or WWRITE unknown (or any other internal error msg) command instead of saying it is already possible.
No Offence.

______________________________
'n chillout

chillout___:

Type /debug @debug and watch the window as you type /wrrite

You will see which raw numeric pops up when the SERVER (yes, the server) sees an unknown command. For reference, it's 421. You can then script those raw events with /help raw events

I never said "* unable to resolve server" was a server error. This one is in fact internal. However, again, I'm not sure what benefit catching this error would have besides theming error messages. Note that you can sort-of catch this one with ON DISCONNECT.