If you know your java or your PHP 5 (yes, go look at the slideshow), you'll have come across the error/exception handling mechanism of try/catch...

For those that don't know, here's a -PSUEDOCODE- example:
alias fakething {
try {
echo -s $ip $nick $ticks
return YAY
} catch (ExceptionType e) {
return ERROR! Something went wrong!
} finally {
echo -s Errors occured!
}
}

What happens is that if for some reason $ip, $nick, or $icks, or even echo -s doesn't work, instead of spitting out * Invalid parameters; blah line blah, it would return "ERROR! Something went wrong!", and execute the code in the finally {} statement.

This is good for situations like working with com objects, where if something goes wrogn in a majro fashion, you want to close the com object down before returning from the alias.
Or with sockets. Or anyhting that blurs the line of robustness (DLL calls...)

you could also customise errors to be handled by aliases, view a /throw command;
ie
try {
echo -s Making an error on purpose!
throw CustomErr $1-
}

alias customerr {
echo -s An error occured with the parameters: $1-
}

Output would be:
Making an error on purpose!
An error occured with the parameters: blah blah

Its possible to do with a tangle of goto loops, but thats just not friendly.

hmm... not that bad ... I whould use it ..

Heh I love this. I posted this a while ago and got responses like "mIRC isn't C++" "mIRC isn't OOP" etc. Now when you post it you get "thats the greatest idea anyone ever proposed!!!"

But anyway, there is a flaw with your design there, "ExceptionType" mIRC has no concept of types, it is not a type based language. I think adding a type system solely for use in exceptions would be a bad thing.

It was probably me :tongue: and if so, I wasn't necessarily objecting to it, I would have just stated that I had no use at all for such a thing. I forget what was said in the posts though I do know one thing, I might have objected to mIRC's scripting language undergoing huge changes to accomodate what you just mentioned would not be possible.

Ah but here's where we use our wildcards to match the errors;
wheter its invalid syntax or missing parameters or no such command, or WHATEVER...

try {

} catch (*) {
/globErrHandler $1-
}

try {

} catch (*syntax*) {
/synErrHandler $1-
}

Yes I'm just saying all exceptions should be "strings" they shouldn't be InvalidParamType or something to that affect.

hey man, this is an awesome suggestion and i would love to see it in there. I program in Visual Basic .NET and it uses this and it is a saviour in many situations.