I have taken over an Electron project from another developer.
The problem I am facing is that the project does not show any errors. Even including something like throw "this is an error" does not produce any output on the main process or render process consoles or any sort of standard error popup.
I have checked to confirm that electron-unhandled is not in use and that nothing registers 'uncaughtException'.
What am I missing that could cause this behavior?
Search for: unhandledRejection
unhandledRejection : This will catch any thrown errors, or non fatal errors you have successfully handled via throw.
uncaughtException : This only catches fatal errors or errors that would crash your node instance
WebWorkers : There will be yet another console for webworkers if your using those.
package.json : Take a look in here at the script executed to start electron or however your starting it... Make sure the console is not being sent to a remote console. This feature would allow for debugging the application via Chrome/Firefox vs the standard console. Pretty common for electron apps. If is done via the startup command.
May look something like this:
process.on('unhandledRejection', function (err) {
});
Also, make sure you include any modules in your searching for suppressors as the issue may exist somewhere in the node_modules directory and many IDE's (mine does by default) exclude that directory in indexing/searches.
Another possible reason could be stdout and/or stderr redirection, the problem is this could be achieved by several ways so it's hard to suggest you what to check...
If there is some child_process call to launch a sub-process you could check the stdio array used, or you can check if some low level operation is performed against file descriptors 1 and 2...
Hope this helps.
Are you facing the problem as mentioned in this official thread. You may disable the original event listeners and manage the ELECTRON_BROWSER_WINDOW_ALERT event by my event listener.
Here is the solution
ipcMain.removeAllListeners("ELECTRON_BROWSER_WINDOW_ALERT")
ipcMain.on("ELECTRON_BROWSER_WINDOW_ALERT", (event, message, title)=>{
console.warn(`[Alert] ** ${title} ** ${message}`)
event.returnValue = 0 // **IMPORTANT!**
})
Related
I'm currently starting to write some TestCafe tests, and came across an issue in our website whilst running them - a JS error in the console fails the test. Naturally, I was quite pleased that my test had caught this, but it would mean that even if a JS error happens that is low priority and affects no users directly, our tests may fail and prevent a build.
Now this may be a workflow some want, but for us we'd rather raise a ticket and address it in a parallel workflow rather than block everyone because of a JS error. I'm aware of the --skip-js-errors option, however this just throws away all the errors entirely. Is there a middle ground, like converting the errors to warnings, or simply adding some sort of after-test function that logs out any JS errors that occurred during the test run? I've tried adding an afterEach to my fixture like so:
.afterEach(async t => {
const { error } = await t.getBrowserConsoleMessages();
console.log(JSON.stringify(error));
});
But with --skip-js-errors this does nothing. I'd love some pointers on this please!
My goal, in case it wasn't clear - I want to see the possible JS errors in my TestCafe run so that I can log them and make tickets off them, but I don't want them to fail the test run.
TestCafe does not provide such functionality out of the box. As you correctly mentioned, the --skip-js-errors flag ignores all errors and does not log them.
However, you can achieve the desired functionality using the Script Injecting mechanism. Please refer to the following article for more details: https://devexpress.github.io/testcafe/documentation/using-testcafe/common-concepts/inject-scripts-into-tested-pages.html#inject-script-code
I recommend you continue using the --skip-js-errors flag and add a custom window.onerror handler. Please see the example:
fixture `fixture`
.page `../pages/index.html`;
test.clientScripts({
content: `
window.addEventListener('error', function (e) {
console.error(e.message);
});`
})(`Skip error but log it`, async t => {
console.log(await t.getBrowserConsoleMessages());
});
In this code, I add the error event handler. Inside the handler, I call the console.error method. In this case, t.getBrowserConsoleMessages will return the correct log of errors.
Please use this approach along with the --skip-js-error flag.
Thus, the command will be the following: testcafe chrome test.js --skip-js-errors.
I've got a little sandbox project I've been playing around with for the last few weeks to learn the in's and out's of implementing a TestCafe runner.
I've managed to solve all my problems except one and at this point I've tried everything I can think of.
Reviewed the following similar questions:
How to close testcafe runner
How to get the testCafe exit code
But still my problem remains.
I've toyed around with my argv.json file.
I've toyed around with my CICDtestBranches.json file.
I've toyed around with my package.json file.
I've tested the same branch that has the problem on multiple
machines.
I've tested with multiple browsers (Firefox & Chrome) -
both produce the same problem.
I've tried to re-arrange the code, see
below
I've tried add multiple tests in a fixture and added a page
navigation to each one.
I've tried to remove code that is processing
irrelevant options like video logs & concurrency (parallel execution)
I also talked with some coworkers around the office who have done similar projects and asked them what they did to fix the problem. I tried their recommendations, and even re-arranging things according to what they tried and still no joy.
I've read through the TestCafe documentation on how to implement a test runner several times and still I haven't been able to find any specific information about how to solve a problem with the browser not closing at the end of the test/fixture/script run.
I did find a few bugs that describe similar behavior, but all of those bugs have been fixed and the remaining bugs are specific to either Firefox or Safari. In my case the problem is with both Chrome & Firefox. I am running TestCafe 1.4.2. I don't want to file a bug with TestCafe unless it really is a confirmed bug and there is nothing else that can be done to solve it.
So I know others have had this same problem since my coworker said he faced the same problem with his implementation.
Since I know I am out of options at this point, I'm posting the question here in the hopes that someone will have a solution. Thank you for taking the time to look over my problem.
When executing the below code, after the return returnData; is executed, the .then statement is never executed so the TestCafe command and browser window are never terminated.
FYI the following code is CommonJS implemented with pure NodeJS NOT ES6 since this is the code that starts TestCafe (app.js) and not the script code.
...**Boiler Plate testcafe.createRunner() Code**...
console.log('Starting test');
var returnData = tcRunner.run(runOptions);
console.log('Done running tests');
return returnData;
})
.then(failed => {
console.log(`Test finished with ${failed} failures`);
exitCode = failed;
if (argv.upload) return upload(jsonReporterName);
else return 0;
testcafe.close();
process.exit(exitCode);
})
.then(() => {
console.log('Killing TestCafe');
testcafe.close();
process.exit(exitCode);
});
I've tried to swap around the two final .then statements to try and see if having one before the other will cause it to close. I copied the testcafe.close() and process.exit() and put them after the if-else statement in the then-failed block, although I know they might-should not get called because of the if-else return statements just before that.
I've tried moving those close and exit statements before the if-else returns just to see if that might solve it.
I know there are a lot of other factors that could play into this scenario, like I said I played around with the runOptions:
const runOptions = {
// Testcafe run options, see: https://devexpress.github.io/testcafe/documentation/using-testcafe/programming-interface/runner.html#run
skipJSErrors: true,
quarantineMode: true,
selectorTimeout: 50000,
assertionTimeout: 7000,
speed: 0.01
};
Best way I can say to access this problem and project and all of the code would be to clone the git lab repo:
> git clone "https://github.com/SethEden/CAFfeinated.git"
Then checkout the branch that I have been working this problem with: master
You will need to create an environment variable on your system to tell the framework what sub-path it should work with for the test site configuration system.
CAFFEINATED_TEST_SITE_NAME value: SethEden
You'll need to do a few other commands:
> npm install
> npm link
Then execute the command to run all the tests (just 1 for now)
> CAFfeinated
The output should look something like this:
$ CAFfeinated
Starting test
Done running tests
Running tests in:
- Chrome 76.0.3809 / Windows 10.0.0
LodPage
Got into the setup Test
Got to the end of the test1, see if it gets here and then the test is still running?
√ LodPage
At this point the browser will still be spinning, and the command line is still busy. You can see from the console output above that the "Done running tests" console log has been output and the test/fixture should be done since the "Got to the end of the test1,..." console log has also been executed, that is run as part of the test.after(...). So the next thing to execute should be in the app.js with the .then(()) call.....but it's not. What gives? Any ideas?
I'm looking for what specifically will solve this problem, not just so that I can solve it, but so others don't run into the same pitfall in the future. There must be some magic sauce that I am missing that is probably very obvious to others, but not so obvious to me or others who are relatively new to JavaScript & NodeJS & ES6 & TestCafe.
The problem occurs because you specified the wrong value for the runner.src() method.
The cause of the issue is in your custom reporter. I removed your reporter and now it works correctly. Please try this approach and recheck your reporter.
I'm facing an issue while debugging my application. Following is the architecture:
Server: Java (Servlet)
Client: React+D3
Problem: Whenever, I change some react or d3 code and if an error occurs then it just shows me that some react (or d3) error has occurred but never tells me which function the error occurred (as seen in snapshot). Now, I know that simply debugging it by having the information like variable name and searching where I defined that variable. However, situation becomes tough when I use same object multiple times (say window) and had made several changes in the code. In this case, a specific line number where the error occured can be handy and quick. Let me know if I'm missing some basics about debugging such applications?
EDIT1:
1. In the snapshot, http://localhost:8080/..../Server Server is the main servlet application, kind of launchpad, which triggers several other react-based js files.
2. The mentioned ReferenceError is inside a function updateWindow() but the console never mentions this (and that's my problem).
PS: I'm using Eclipse tomcat on server-side
I think there's no straight forward solution to this problem. So, I'll post the method that worked for me with few additional points:
Problem: It doesn't gives a nice error trace like standard Java application, probably because it mixes with JavaScript code.
At every line of the error trace, line:column specifies the error line. I used this as a reference and started manual debugging from where my application launches i.e. Server.java and look where I defined the createChart() in the JS file and drill-down until I found the referenced variable.
In case of ReactJS' error (an error after resolving reference issue), I debugged it with normal react.js (not minified version react.min.js) so that it shows me exact line of error. Minified version is cluttered and is useless while debugging.
PS: If someone has better answer I'll edit this in future.
Despite my extensive experience with nginx, apache, jboss etc. servers, I am very new to nodejs server (It took my interest for socket.io features). I find it strange that unexpected data like say object.MyProperty (which is undefined) etc - which are trivial in my opinion, cause the entire server to crash (it doesnt crash for that client request, but the entire server crashes!) and you need to restart the server.
I am not sure if it is because I am on development mode or it will be like that on live mode as well. When it crashes, all runtime data get lost.
My question is that what should I do make sure that the server doesnt crash but it can write issues to the log file like in other servers.
Any assistance is much appreciated.
You can use try catch blocks for this. And log them under catch.
Updated:
Also, Node being single process based, uncaught exceptions leads to crash (of that process). One of the methods suggested is to use domains.
Example:
domain = require('domain'),
d = domain.create();
d.on('error', function(err) {
console.error(err);
});
d.run(function() {
...
Ref. is a good article and explains in short various approaches to handle the problem.
process.on('uncaughtException', function (err) {
console.error((new Date).toUTCString() + ' uncaughtException:', err.message)
console.error(err.stack)
})
Since nodejs is a single process server, you can place this code anywhere in js script for this to act as a catch all for unhandled/unforeseen errors.
I think you are looking for https://github.com/foreverjs/forever. Forever runs a script forever and restarts it in the event of a crash without user intervention.
You can install forever using npm. Once installed, you can run your nodejs scripts using forever start <path/to/script>. forever list will list all the currently running scripts and forever stop <script-id> will stop a given script.
Keep in mind that using this doesn't mean you don't have to do proper exception handling. Implement try...catch statements as needed and handle all exceptions in code.
The best way to do this would be for you to validate all your incoming post request bodies using a json schema validator. There are several available that are really fast and will add very minimal overhead (less than 1 ms) to your overall response time. I'm the author of one such validator called Themis which we use for REST APIs. There's also a comprehensive benchmark which compares all the available JSON schema validators.
This would prevent your sever from crashing and becoming unavailable simply because of a bad request.
I'm running tests with jasmine/karma and although all tests run ok, process exits with 1. I suspect that these are Firefox's web console error messages, which are produced when I try to add existing record into IndexedDB object store. Is there any option to disable these messages or ignore them in Karma runner?
UPD: These errors occur in web console even if I wrap my code inside try..catch, so it's browsers default behaviour.
https://travis-ci.org/1999/sklad/builds/36609101
Just in case someone needs this. The answer is here. In brief, Firefox shows that this is a usual DOM error and it has default behavior. So if you prevent default 'onerror' behavior which is 'abort', everything goes fine. You can see the result here.