Currently the library does not handle exceptions thrown when attempting to spawn the dig process making them hard to handle in code using the library.
This adds a listener to catch those exceptions.
Easiest way to test is to simply uninstall dig like this:
yum remove bind-utils -y
Even if you have a catch on your dig usage like this:
it('Query A for google.com and return raw result', (done) => {
dig(['google.com', 'A'], { raw: true })
.then((result) => {
expect(result).to.be.a('string');
done();
})
.catch((err) => {
console.log('Error:', err);
});
});
You will still get an uncaughtException error. In this case you will get a spawn dig ENOENT uncaught exception. Adding the handler allows these errors to be caught and handled in the catch block.
Wasn't entirely sure what the best way to write a test for this would be as I think it would require stubbing out the spawn call to just throw an exception but I think the error event should be handled.
Currently the library does not handle exceptions thrown when attempting to spawn the dig process making them hard to handle in code using the library.
This adds a listener to catch those exceptions.
Easiest way to test is to simply uninstall
dig
like this:Even if you have a
catch
on your dig usage like this:You will still get an
uncaughtException
error. In this case you will get aspawn dig ENOENT
uncaught exception. Adding the handler allows these errors to be caught and handled in thecatch
block.Wasn't entirely sure what the best way to write a test for this would be as I think it would require stubbing out the
spawn
call to just throw an exception but I think theerror
event should be handled.