gundb / panic-server Goto Github PK

If a job throws an error asynchronously, the panic coordinator won't be notified (however node.js will log an error message, or call 'uncaughtException' on it's process).

Example:

function error (done) {
  setTimeout(function () {
    throw new Error('Out of bacon.')
  }, 1000)
}

// Run the jobs in parallel
panic.clients.run(error)
panic.clients.run(error)

// The promise resolves

Since the jobs are asynchronously parallel, it'd be pretty difficult to track down which job it belongs to, and report back to that job ID - but I've got an idea!

Solution?
Use the line number. window.onerror is supported in IE6, and will always pass the line number as the third param, which can be used to look up the job. Since we have the luxury of using eval, each job function could be prefixed by a bunch of whitespace, creating a fake "file" that addresses job instances by the line space they occupy.

So: 500 newlines prefixed to a 10 line function. We address the job instance as 500-510. If anything calls the global error handler ('uncaughtException' or window.onerror), grab the line number (say 507), go to the lookup "table", and see what job corresponds to that space. If it exists, call job.fail(error), otherwise ignore it.

Admittedly hacky, but it just might work.

The readme doesn't cover the client .get and .set methods. They're critical to keeping tests modular without exposing globals or mutating shared objects.

More details in this panic-client commit message.

Hi there, is there a more complete example on testing collaborative app? Say a collaborative spread sheet like Google sheets?

The bluebird dependency used within this package is unneeded in modern javascript engines. All I've tested recently include native promises.