Add support for error 477?

[bmcallis]

When trying to join ##java on freenode, I'm getting a 477 command as the response. That command isn't in the switch statement in the raw listener, or in codes.js. So it's falling through to the default case and has a commandType of normal so it's only being log. Which means that I can't handle it to let the user know they can't join the channel.

Here is the log

20 Jul 16:15:32 - Unhandled message: { prefix: 'weber.freenode.net',
  server: 'weber.freenode.net',
  command: '477',
  rawCommand: '477',
  commandType: 'normal',
  args:
   [ 'nickname',
     '##java',
     'Cannot join channel (+r) - you need to be identified with services' ] }

Would it be possible to add that code so it gets emitted as an error? Or possibly emit unhandled messages so the client can handle them somehow?

[Throne3d]

You raise a good point! I didn't know there was a switch statement for the raw message – that seems weird and I'll look into it. This is an error that should probably be handled properly also. Thanks.

[Throne3d]

Oh. You mean the switch statement inside the raw handler doesn't include it? You should be able to handle this message specifically, for now, by adding a raw listener and checking by code.

An event for unhandled messages, separately, sounds like a good idea, as does handling this specific message. I'll get to that.

[bmcallis]

I did add a raw listener so I can handle it in the meantime.

Yeah, that's the switch statement that I was referring to. Even if it was just added to codes.js with a type of error it'd fall through and get emitted as an error.

Thanks for forking this project and maintaining it.

[Throne3d]

No problem!

So it looks like error 477 has conflicting usage. http://defs.ircdocs.horse/defs/numerics.html#err-nochanmodes-477 puts it as both ERR_NOCHANMODES in the RFC2812 IRC spec and ERR_NEEDREGGEDNICK with some particular servers (Bahamut, ircu, Unreal). I've decided not to give it a name in the codes.js file, at least for now, but I've marked it as an error so you should be able to catch it in the regular error event.

[Throne3d]

PR #24 adds a new event, unhandled, which you should be able to catch and receive unhandled messages through. (See ce184fd and sorta d295563.)

[bmcallis]

Thanks for updating this, I've been pointing to the latest commit and it's been working well. Do you think you'll be able to release a new version with it soon?

[Throne3d]

I was planning on trying to get some other changes in before I do that – mostly bumping up the test coverage – but I probably don't really need to. Hm. I should have a new version out in about a week? I'm not sure about earlier than that, though, I'm trying to avoid doing too many new releases in a short period and I expect I'll find more changes I want to get through after looking through the codebase some more.

[bmcallis]

That makes sense and sounds good to me. Thanks

[Throne3d]

A bit later than I expected, and with less in the way of tests than I'd hoped (#29 lists the ones I hope to add soon, but it's a long list and kinda tedious to get to), but I've now released v0.7.0! Hopefully it all works as expected and I didn't accidentally mess anything up.