I'm building a small application with ReactJS and sometimes find it difficult to debug it.
Every time I make some Javascript error, like missing let/var in front of new variable, missing require for a component that I later use, my application just stops working (the code does not execute beyond the line where the error is), but I'm not getting any errors in browser's console. It seems as if some ReactJS code was intercepting errors, maybe handling them some custom way. Is there anything like that in ReactJS? How can I see errors in the console?
I'm using gulp/gulp-connect/browserify set to run the application.
Let me know if you need any additional data or code samples, I'll update the question.
If you know that an error is thrown but swallowed by some other code, you can enable in your browser's debugger to pause execution when an exception is thrown, even if it is caught somewhere:
Note however that libraries sometimes deliberately trigger exceptions while testing whether the browser supports certain features. You'd have to step over those.
Usage of React Hot Loader which is a Webpack plugin should solve most of the problems you have in a development process. It's easy to integrate into existing project and has quite a few examples how to put all the things together.
As a result:
your code changes would be pushed to the browser
in case of the error you will have meaningful stack trace in the browser console.
I'm guessing that the incorrect JS syntax is causing your gulp process to fail which would result in your application not being bundled/deployed in the browser at all.
It seems like there should be errors in your system console (where gulp is running) - as opposed to your browser console. Possibly your gulp process crashes when this happens too. If there are no errors in your console, you may have to listen for them. This post has an example of how to log errors from browserify:
gulp.task('browserify', function(){
var b = browserify();
b.add('./main.js');
return b.bundle()
.on('error', function(err){
console.log(err.message); //
this.end();
})
.pipe(source('main.out.js'))
.pipe(gulp.dest('./dist'));
});
Probably the best solution is to run your code through jshint before browserify so that you aren't trying to browserify syntactically invalid code.
Caveat: not a current gulp user
I suffered from the similar problem with this like missing let/var, require, and other trivial mistakes inside of the react context.
In my case, the cause is the mistake of Promise statement. Promise seems to suppress any exceptions that occur after it is called.
I could resolve the problem by handling exception like below.
var Promise = require('es6-promise').Promise;
var promise = new Promise(...)
promise
.then(function(data){...})
.catch(function(e) {
console.error(e.stack)
}
react-slingshot is a starter kit and it shows error at compile time and shows stack trace on the browser. It also has testing set up.
Related
My goal is to debug one of my tests. I'm using Mocha as a base, and SinonJS for spies, stubs and mocks. For some unknown reason my stub of the ajax method has stopped working. It worked a week ago, now the requests are sent and the stub does not track the calls.
I have these lines inside the outermost describe
let sandbox = sinon.sandbox.create();
let ajaxStub = undefined;
and then this:
beforeEach(function () {
ajaxStub = sandbox.stub($, 'ajax');
});
afterEach(function () {
sandbox.restore();
});
Anyway, my question is not what's wrong with this, I'm probably doing something extremely stupid elsewhere, and some debugging could probably solve it. My problem is with the debugging itself.
mocha --debug-brk --inspect ./test/mytest.js
This is what I run in command line to get the debugging session going.
My problem is to run the tests I'm currently using Gulp, with which I'm loading all my framework dependencies and all my globals - the libraries added this way include also jQuery and sinon
And of course, if I debug my tests using that command line, NodeJS does not load the required files in the environment, and at the first reference to sinon I get an exception.
I could create an html page in which I load required files and tests and run the test - then debug it manually with the browser inspector - but that's something that I would like to avoid. Is there anything more automated?
I'm not a NodeJS expert, I just roughly understand what it is and how it works, so I'm pretty confident there could be something I missed that can be of help :)
What I'm thinking about right now is a batch script to find the required files, but that's all I have.
Just an additional note: code base is really old and big, and I do not really have permission to refactor existing code into es6 modules.
I found a solution: I'm going to create a testDebugLoader.js script in which I will write which test I want to debug, and an array of paths to scripts I need to load.
Then loop trough the array, load each needed file, and call eval on the retrieved text.
I have the following message, just before a failing test:
1) "before each" hook
That is the the entire message. It is in red, which makes me think there is something wrong with the before each hook, but I'm unsure of what the error is. It could be:
A failed timeout
A failed assertion
An Error being thrown
How do I know what the error is?
This particular beforeEach() normally executes perfectly fine.
I ran into this problem when in the beforeEach I accidentally called done() twice (I called it once at the end of the beforeEach, but also called it again via an async function called in the beforeEach).
When I ran the tests in watch mode I got the error message you described without any additional information; when I ran the tests normally I did not get any errors. I reported this on a related ticket.
How do I know what the error is?
Debug it just like you would any normal code. If you are making assertions inside a beforeEach callback, you are abusing the framework. Assertions belong in the it callbacks, so refactor that.
It's also probably not just forgetting to call done because mocha has a clear error message when that happens.
Thus your code is probably throwing an uncaught exception and you can use your favorite flavor of debugging to track it down. I like running mocha with --debug-brk and debugging with node-inspector, but some console.log statements should also suffice. Note passing only the relevant test file to mocha and using the describe.only or it.only techniques can keep the test suite small and focused while you track down the root cause.
This is happening due to the time limit exceeding. In mocha, 2000ms is the maximum time allocated for an async process. So to make your code successful, you to increase the time limit
It is usually done by using the code:
this.timeout(4000)
Note: you can't use the arrow function because you can't use the
this
option in arrow function.
For each of your tests, when you want to append the end call,
dont use:
.end(done())
use:
.end(done)
Currently using the stacktrace.js for logging all my errors in my Angularjs app as below
app.factory('$exceptionHandler', ['errorLogService',function (errorLogService) {
return function (exception, cause) {
errorLogService.log(exception.message, cause);
};
}
]);
this service will log every error occurred in my app. My question is, can we choose certain types or levels of errors to be logged? I'm pretty sure that I'm logging every damn thing! which is causing a lot of headaches..
AFAIK stacktrace.js has no feature to specify certain types or levels of errors to be logged. That is because JS has no standard error type or error level. A script error is an error - that's all! Having said that - problem seems to be in your coding style. Why should there be so many errors thrown in JS code? So many errors in JS code will clutter the whole console and make the logging useless. Only solution I can think of is to fix the errors so that the logs get cleaner. There should be zero such errors in console before you go live - if you have tested your code properly.
tl;dr When there is an error with a test written in intern I don't seem to get error messages that describe on which line the error occurred. I've found a workaround but its not really the ideal solution as it involves messing with code in dependent projects. Does any one have a better way / am I just doing it wrong? Thanks!
Details :
I've seen several times that when there is an issue with parsing a test written in intern (for example failing to close brackets, quotes etc.) that the actual line where the error occurred is not reported, and there is only an error like this (I've subbed in for the actual path as its a work project, but you get the gist):
SyntaxError: Unexpected identifier
at Function.vm.runInThisContext (<myproject>/node_modules/intern/node_modules/istanbul/lib/hook.js:163:16)
at <myproject>/node_modules/intern/node_modules/dojo/dojo.js:745:8
at fs.js:266:14
at Object.oncomplete (fs.js:107:15)
I poked around a little and discovered that there's an undocumented(? - its not in here) parameter for vm.runInThisContext, which if enabled actually provides details of the original error (here and here) - there's some discussion about how this will play out but if I switch dojo.js and hook.js in istanbul (if its running) to use this parameter, I get error messages like this :
<myproject>/test/publisherConfigSpec.js:16
errorCb cat = dfd.rejectOnError(function(error) {
^^^
SyntaxError: Unexpected identifier
at Function.vm.runInThisContext (<myproject>/node_modules/intern/node_modules/istanbul/lib/hook.js:163:16)
at <myproject>/node_modules/intern/node_modules/dojo/dojo.js:745:8
at fs.js:266:14
at Object.oncomplete (fs.js:107:15)
which is the output I want (or at least massively improves my chances of finding and fixing the error) but its not ideal to be messing about with the node dependencies, and it seems to me that it may be too much in flux for a pull request (see most recent update to the API) Is there an alternative way of getting useful output when there's an error parsing the test code input?
Thanks for any advice :)
The output that Node.js provides for SyntaxError is obviously not great, but we probably won’t use undocumented features (they’re undocumented for a reason!) in any official release of Intern to make it work differently. Non-syntax errors (runtime errors) will be caught and reported competently by Intern to whatever reporters you are using.
In this case, I’d advise you to use an editor that includes support for syntax checking: Komodo Edit/IDE, WebStorm, SublimeText, Eclipse, vim… if you get to the point where you are trying to run syntactically invalid code, your code editor is failing you by not telling you soon enough that you’ve made a mistake.
I seem to be running into an odd problem. When using my GWT application in a local environment, everything works as it should. The problem comes in after I compile and deploy my application. When I go through my project workflow and click on a certain link to switch into a new panel, I get the following error (from my console in Chrome):
Uncaught com.google.gwt.event.shared.UmbrellaException: One or more exceptions
caught, see full set in UmbrellaException#getCauses (anonymous function)
This error is thrown by one of the cache file generated by GWT at compile time. But this never happens on the locally deployed program (deployed from Eclipse, "Run as Web Application"). Has anyone ever run into this issue or can provide any direction for a fix?
Thank you! :)
I had the same problem just now. Works locally, fails with the mentioned Javascript console error, nothing in server logs.
Turns out that client Java code (which is complied to Javascript) had try/catch block which worked when executed in Java, but failed silently when compiled to Javascript. I'm still not sure what was the exact nature of the problem, but try removing try/catch blocks.
(It seems that in my case, table.getWidget() call was failing and throwing exception.)
I had the same problem, i think interpretation of try catch is not the same than in Java... after gwt compilation, when you are in catch case, the execution failed. If you open firebug, you can see point of errors into JS.
I had the same problem, it worked in development mode. Then, after I compiled I would get an error. To fix, I had to get rid of:
try{
//some code
} catch(NullPointerException ex){
//more code
}
Instead I did:
if(variable != null){
//some code
} else {
//more code
}
After that it worked perfectly.