Using mocha.throwError for better async error handling

[jpbochi]

This is a follow up to mochajs/mocha#985

[coveralls]

Coverage remained the same when pulling 1baa0f8 on jpbochi:async-error-handling into 0e560c6 on chaijs:master.

[coveralls]

Coverage remained the same when pulling b127b01 on jpbochi:async-error-handling into 0e560c6 on chaijs:master.

[jpbochi]

Travis is a little crazy. It passes as a PR for chai, but fails as a branch on my fork.

[jpbochi]

@travisjeffery @visionmedia Hey, have you got time to take a look at this PR?

[logicalparadox]

Chai strives to remain test runner agnostic. Inclusion of this PR would violate that principle. Our plugin api is robust enough to have this implemented as a plugin.

Furthermore, this PR implements this for the assert interface but ignores the chainable interfaces (expect, should).

[diversario]

So, this idea is dead? Is there a plugin or anything that implements this?

[jpbochi]

@diversario I guess I was just blocked, and I never got time to try this as a plugin as it was suggested. Interesting enough, making the necessary change on mocha was easier.

[diversario]

😑Lame.
So, you have some workaround that you use yourself for this?

[jpbochi]

I've been away from node.js for a while, so I don't remember the details any more.

I was reviewing some of my stale code now. In my case, I think the async code was all inside a jQuery.Deferred object. Apparently, my solution was to make sure mocha's done callback for sync tests by passing done to the deferred.always. Here's an example: https://github.com/jpbochi/duelo/blob/master/tests/api/game_tests.js#L21-L28

As I said, I don't remember exactly. This .always(done.bind(null, null)); might be there for another reason.

hope it helps.

[diversario]

Thanks, @jpbochi.