That would also mean that if a header is sent in on sockopen event, I have to check after every /sockwrite if $sockerr is > 0, I saw nobody doing that so far?
No, the error check should be done only once, generally at the top of the event.
Let's take an example (which is the way things should be done)
On *:SockOpen:Name:{
If $sockerr { Echo -st - Error on $sockname - | Return }
Var %s = SockWrite -n $sockname
%s NICK SomeNickname
%s USER something something something :Just Testing
}
Of course, something like the following is useless.
On *:SockOpen:Name:{
If $sockerr { Echo -st - Error on $sockname - | Return }
Var %s = SockWrite -n $sockname
%s NICK SomeNickname
If $sockerr { Echo -st - Error on $sockname - | Return }
%s USER something something something :Just Testing
If $sockerr { Echo -st - Error on $sockname - | Return }
}
Because, in the case of an error, the socket is automatically closed by mIRC, so a unique check will do it.
NB: Note the use of "Var %s = SockWrite -n $sockname", which is not a compulsory method. I like to do that when I'll have to do a series of /sockwrite. It then neatens the source. It's only a matter of taste and aesthetics.
Thats rather contradiction, as said, according to the help, any of the /sockwrite's can cause $sockerr to be > 0, so if only a check after the on sockopen event, it would be possible that for example the first /sockwrite fails with an error, so the socket is then closed by mirc but the code from the event keeps running until the end, return or halt, so this would halt it with an error in status, and it's also possible a script has to perform certain code in case of failure so it has to check $sockerr everytime because mirc stops executing after an error and the script wouldnt be able to perform that code anymore (or it would need an :error label)
So an unique check will not do it then.
Another text from the help:
"On error: if a /sockwrite fails, it sets $sock().wserr to the error value, and triggers the on sockwrite event with $sockerr set."
The help really sucks when it comes to details.
It doesn't say it triggers the on sockwrite AFTER the current code has finished executing, so it would mean then that mIRC triggers the on sockwrite event with $sockerr check - immediately, similar to /signal -n (so far the only such case I know is when doing /disconnect, the on disconnect event is triggered, and then mirc proceeds executing the code after /disconnect)
It's all...guessing.
