Does anyone know if there a way to disable error handling by Mocha?
I'd really like to let the exception bubble up and be handled by the browser during debugging.
Update:
The context is this.
- Some code throw's an unexpected error.
- I would like to disable "try/catch" (something like jasmine's tests do) and be thrown into the debugger in chrome.
This way I can inspect the current state of the application at that moment.
It sounds like there isn't something built in, and I will need to manually do this each time I get some odd error in a test. Maybe by wrapping my code with
try {
somethingThatBreaks();
} catch(e) {
debugger;
}
Mocha installs its own onerror handler to trap exceptions that may occur in asynchronous code. You can disable it with:
window.onerror = undefined;
This is dangerous. You should do this only when you must absolutely do so. If you make this a routine thing, Mocha will completely miss errors that happen in asynchronous code.
If what you want to do is let exceptions in synchronous code bubble up, I'm not seeing what this would accomplish. If you want to inspect the exception before Mocha touches it, a try...catch block wrapping your test will do this.
Mocha's error handling is contained in the following code:
if (this.async) {
try {
this.fn.call(ctx, function(err){
if (err instanceof Error || toString.call(err) === "[object Error]") return done(err);
if (null != err) return done(new Error('done() invoked with non-Error: ' + err));
done();
});
} catch (err) {
done(err);
}
return;
}
// sync
try {
if (!this.pending) this.fn.call(ctx);
this.duration = new Date - start;
fn();
} catch (err) {
fn(err);
}
You could possibly throw the error with the catch (or remove the try..catch entirely) however it would most likely break the test suite if a test fails.
mocha.options.allowUncaught=true
But in this case, the rest of the tests will break if the error is not caught within mocha. Disabling try{} catch(){} in mocha will only be useful when debugging.
To create a test, I suggest using the construction
(for browser)
try{
throw new Error()
} catch (e){
// Let's say it's called in a yor error listeners.
e.handler=()=>{
done(e)
}
let event= new ErrorEvent('error',{error:e})
window.dispatchEvent(event);
}
Related
I'm still learning the language, and I'm very curious to know what is the proper way to ensure that either all functions will execute or none when one action requires series of functions to be executed. For example I might have an HTML button that calls some apply() function:
function apply() {
try {
// Check arguments, choose what exactly to do next through some IFs etc...
}
anotherFunction();
}
function anotherFunction() {
try {
// Request data from DB, process data received, update object variables, etc...
}
yetAnotherFunction();
}
function yetAnotherFunction() {
try {
// Update HTML
}
oneMoreFunction();
}
function oneMoreFunction() {
try {
// Update graph
}
}
So the problem here is that if any of the functions in the flow throws an error the rest functions won't do what they should, hence the entire Apply process will be interrupted with some changes applied (let's say HTML is getting updated) but the rest (the graph) is not. I'm curious to know what is the best practice to prevent this behaviour? Yes I'm trying my best to use try {} and check arguments for errors etc, but it looks like I can't foresee everything, I just need some way to tell the code "ensure you can execute all of the functions, in case of any errors, just don't do anything at all". Please advise what can be done here?
You're taking the right path when thinking about try/catch blocks, but notice I used a 'catch' as well. Usually (maybe that is even enforced, I can't remember) you need the catch blocks along with the try.
So your functions could look something like this:
function async myFirstTryCatch() {
try {
// Make your request in the try block
await requestCall();
} catch(error){
// Hey, my http call returned an error
// Deal with the error here. Maybe show a toast, validate a form
// Anything you need to not break the code and have good UX
console.log(error)
}
}
In that same line of thought, you could have each function handle their own try/catch or maybe control that in your apply function, in case some of the chain must continue/stop depending each other.
function apply() {
try {
firstCall();
functionThatRequiresFirstCalltoSucceed();
} catch (error){
//Will catch if either firstCall or functionThatRequiresFirstCalltoSucceed fail
console.log(error)
}
functionThatIndependsFromTheResultAbove();
}
I hope this will help you build your thoughts about error handling in JS :)
IMPORTANT NOTE
If your code enters the catch block, it will consider that the error has been dealt with and will not propagate! Here's an example
function functionThatThrowsError(){
try{
throw new Error('Example Error!');
} catch (error) {
// Error has been dealt with
console.log(error) // Returns "Example Error"
// throw error; <--- Throw the error in the catch block if you need t to propagate
}
}
function wontCatchError() {
try {
functionThatThrowsError();
} catch (error) {
// THE CODE WILL NOT ENTER THE CATCH BLOCK
// SINCE THE ERROR WAS CAUGHT IN THE FUNCTION ITSELF.
// If you need to catch here as well, make sure to throw the error
// in the catch block of the 'functionThatThrowsError'
console.log(error)
}
}
try {
throw new Error('yikes!');
} catch (e) {
throw e;
} finally {
console.log('caught error!')
}
Prints out:
caught error!
Error: yikes!
So is the finally block running before the throw statement?
It only looks like the finally block ran first, but we can see this isn't actually the case:
let failed;
try {
throw new Error('yikes!');
failed = false;
} catch (e) {
failed = true;
throw e;
} finally {
console.log(`caught error! failed: ${failed}`)
}
prints
caught error! failed: true
Error: yikes!
So why is the printing of the error out of band? is there some asynchronous behaviour here that I'm not seeing?
Try runs - Your try runs and throws the error
Catch runs - Your catch catches the error and simply re-throws it.
Finally runs - You print out your string
The rethrown error is now uncaught - And your browser logs details about the error
The finally clause runs before the overall try block finishes. The error that's logged happens when the runtime intercepts the exception, which is after the try block finishes. (Note that your catch code does not console.log() anything. It throws a new exception, but the finally clause will still run before the rest of the world sees that.)
All languages with try catch finally that I know of behave in exactly the same way. The point of finally blocks is to provide a place to put code that is guaranteed to run whether the try succeeds or fails.
The throw statement doesn't print anything. The error is printed later when the browser catches the thrown error.
Having a simple Rxjs stream, i faced this situation:
Rx.Observable
.fromArray([1,2,3,4,5,6])
// if commented from here
.windowWithCount(2, 1)
.selectMany(function(x) {
return x.toArray();
})
// to here .. the error bubbles up
.subscribe(function(x) {
console.log('x:',x)
throw new Error("AAHAAHHAHA!");
});
with the windowWithCount + selectMany the error is silently catched internally and isn't catchable and it isn't notified in console neither
commenting those 2 blocks the error is notified on console at least
I don't think this is supposed to be, or am i missing something?
here the jsbin
Your subscribe function should never throw an exception. RxJs models asynchronous streams of information, where the observer code often runs asynchronously from the producer code (e.g. not on the same callstack). You cannot depend upon errors propagating back up to the producer.
Rx.Observable
.fromArray([1,2,3,4,5,6])
// if commented from here
.windowWithCount(2, 1)
.selectMany(function(x) {
return x.toArray();
})
// to here .. the error bubbles up
.subscribe(function(x) {
try {
console.log('x:',x)
throw new Error("AAHAAHHAHA!");
}
catch (e) { console.log('error: ' + e); }
});
That being said, it looks like RxJS is "eating" this particular exception, which may be a bug. RxJS does its best to raise unobserved exceptions as unhandled exceptions in the host. Looks like in this instance this mechanism isn't working. You should open an issue on GitHub.
Try catch is used to catch errors and report to user. all said and fine. But where exactly one has to put the try-catch. Or What exactly has to go inside try catch on a usual basis.
Most importantly, is it absolutely a good coding practice to have a try catch block?
I think it is good practce to use a try catch if it will handle errors and prevent the program from crashing.
Taken from W3 Schools:
The try statement lets you test a block of code for errors.
The catch statement lets you handle the error.
The throw statement lets you create custom errors.
The finally statement lets you execute
code, after try and catch, regardless of the result.
An example:
fuction foo()
{
try
{
// Block of code to try
}
catch(e)
{
// Block of code to handle errors
document.getElementById("demo").innerHTML = e.message;
}
finally
{
// Block of code to be executed regardless of the try / catch result
}
}
Here is soem more documentation at W3 Schools: http://www.w3schools.com/js/js_errors.asp
Yes, it absolutely good practice to use try-catch blocks. Here's a rather simplistic (but contrived) demonstration.
function safeParseJSON(json) {
try {
return JSON.parse(json);
} catch(exception) {
// could not parse this JSON
console.error(exception);
} finally {
return null;
}
}
Parsing JSON is the most common scenario I have encountered for using the try-catch construct, hence the example.
However, the usual try-catch mechanism doesn't work when the function is asynchronous. It's essential to understand this if you are ever using a server side Javascript platform.
The standard pattern for async event handling is as follows.
db.connect(options, function connected(err, client) {
if(err) throw err;
client.query(...);
});
Because that callback function is run somewhere else (presumably when the database connects) we can't wrap it with a try-catch block. Instead, most async method calls will pass the error as the first argument to the callback.
This way we can handle the error as and when it happens. If there is no error, null will be passed as the first argument, so that it can be ignored.
A number of implementations of promises try to recreate this mechanism, but in an asynchronous way.
Here's an example with Q:
db.connect(options)
.then(function(client) {
client.query(...);
})
.catch(function (error) {
throw error;
})
.fin(function() {
// finally
db.close();
});
You can also use Q on the client side, if you are working with asynchronous functions.
I am modifying a node.js library to support true asynchronous operations.
I am having troubles with Mocha and Chai to make this (a similar) test pass.
it('should throw an error', function() {
expect(function() {
process.nextTick(function() {
throw new Error('This is my error');
});
}).to.throw(Error);
});
The problem is - because of the nextTick - that the Error is thrown out of scope of it and besides the test failing, Mocha also outputs the below.
Uncaught Error: This is my error
What is the proper way to structure this test in order to make it succeed?
Hmm... in a full-fledged application what I'd do is probably use something like Sinon to check that the method that should throw an error has been called and is throwing.
In code where you cannot do this, then the following method would trap the exception:
var expect = require("chai").expect;
var domain = require("domain");
it('should throw an error', function(done) {
var d = domain.create();
d.on('error', function (err) {
// Exit the current domain.
d.exit();
// We must execute this code at the next tick.
process.nextTick(function () {
console.log(err); // Just to show something on the console.
expect(err instanceof Error).to.be.true;
done();
});
});
d.run(function () {
process.nextTick(function() {
throw new Error('This is my error');
});
});
});
This code creates a "domain" stored in d. A domain will emit error events on uncaught exceptions that happen in it so we run the test inside the domain (d.run(...)) we've created and wait for an exception to happen (d.on('error', ...). We check that it is an Error object. (In a real test, I'd also check the error message.) When we are finished we call done() to tell Mocha that the asynchronous test is over.
The handler for error events calls d.exit(). This is to make it so that Mocha can catch the error normally if the assertion (expect(err instanceof Error)...) turns out to fail. If we do not exit the domain, then the domain will trap the error. Also, the check itself must be performed on the next tick to be outside the d domain.
Is Using domain A Problem?
NO!
The documentation for domain comes with some warnings about shutting down operations once an uncaught exception is caught when running an ongoing process, like a server. Then the thing to do is to clean what can be cleaned and exit as soon as possible. However, using domain in a test does not differ from what Mocha is already doing. The way Mocha catches unhandled exceptions in asynchronous code is by using process.on('uncaughtException'. Upon catching an unhandled exception Mocha marks the current test as failed and continues. Yet the documentation regarding uncaughtException says "Don't use it, use domains instead. If you do use it, restart your application after every unhandled exception!"
Ergo, anyone who has a problem with using domain should not be using Mocha in the first place.
You're trying to catch an exception on the incorrect function, the container for the function that throws. Also, because the function is wrapped in nextTick it is executed in a different stack and therefore the exception cannot be captured (this is simply a JS thing unfortunately).
Try this instead:
it ('should throw an error', function (done) {
process.nextTick(function () {
var myFn = function () { throw new Error() };
expect(myFn).to.throw(Error);
// Tell mocha the test is complete
done();
});
});
Update: There is no proper way to structure this test to make it pass as you cannot catch the exception in this scenario. Perhaps update your code to use callbacks to handle errors:
function doSomethingUnsafe() {
try {
// Run code here that may cause exceptions...
callback(null, 'Woohoo! No errors!');
} catch (e) {
callback (e, null);
}
}