Google Drive Realtime API has a nice set of errorTypes that you can listen for, so you can handle each case individually:
https://developers.google.com/drive/realtime/reference/gapi.drive.realtime.ErrorType
Unfortunately, this list doesn't include the DocumentClosed error. For some reason, that error is its own object in the API.
https://developers.google.com/drive/realtime/reference/gapi.drive.realtime.DocumentClosedError
For the life of me, I cannot figure out how to handle this error. I have an onError listener function set up on my realtime.load, but that only catches Errors, which are different than the DocumentClosedError.
Is there any way to handle/listen for this particular type of error? I have also tried document.addEventListener but that was a desperate attempt and didn't work
For anyone else wondering about this, it was related to binding between angular and google drive.
The document was closed for google but the angular binding were still there.
We handled this by intercepting the angular error based on this.
http://odetocode.com/blogs/scott/archive/2014/04/21/better-error-handling-in-angularjs.aspx
The DocumentClosedError is a different type of error as it is only thrown when you are accessing an invalid document. The only times that that Realtime Document should be invalid are: 1) after one of the fatal errors defined in ErrorType is handled by your error function, or 2)after you call .close() yourself on the document.
Tracking whether you hit one of these two conditions on the client and ensuring you don't access the Document afterwards is how to prevent the error from firing. Ideally if you get into a state where your document is closed, the app should teardown its references to the realtime models and reconnect to reduce the number places that you will throw exceptions.
TL;DR: If you're hitting DocumentClosedErrors you should change the way that you handle fatal errors defined in ErrorType.
Related
My sign in with firebase authentication completes successfully. I am using signInWithPopup. It returns a blank screen but does not break the flow. However after logging in, a message appears in my console. The message is :
A boolean is being passed as a fourth parameter to window.open. This is not used and may cause an exception in a future release.
How do I handle this exception?
The second part of the question is what data in response(that we get in promise from firebase sign in with popup) correlates with the above mentioned exception? Is it a completely different problem or does it have anything to do with the blank popup? Thank you in advance. If more information is needed to solve the problem, kindly say so.
This may be a newly introduced bug with Firebase and one of its dependencies. I suggest rolling Firebase to a previous and consistent version for Firebase and its sister modules
Source:
https://github.com/firebase/firebase-js-sdk/issues/4988
For any uncaught exception that occurs in EDT, I show an informative Dialog (useful during the development), I send a crash report to the developer account and, when the user press "OK" in the Dialog, I kill the app. This logic prevents testers from testing the app in an invalid state, that's why I don't use the default crash report functionality of Codename One, but I reimplemented that according to my needs.
To do that, I used Display.getInstance().addEdtErrorHandler(...), that works fine.
Is there any similar API to automatically handle uncaught exceptions in custom threads, like my EasyThread instances? Even better, to automatically handle uncaught exceptions of all threads with few code in the init()?
We don't have thread groups so there is no uncaught exception handlers. But something like that should probably be available for easy thread. It could be pretty powerful as it could allow for a retry of a failed task.
So we'll add new methods: addErrorListener, removeErrorListener, addGlobalErrorListener and removeGlobalErrorListener to the coming update of Codename One.
I'm using the decorator to change the $exceptionHandler behavior, sending logs to the server. My problem with this is that the stackatrace of the exceptions seems useless, showing only part of the stack. For example:
Syntax Error: Token 'undefined' not a primary expression at column NaN
of the expression [expression here].
at Error (native)
at throwError (http://localhost:8080/angular/angular.js:6674:62)
at primary (http://localhost:8080/angular/angular.js:6918:9)
at unary (http://localhost:8080/angular/angular.js:6900:14)
at multiplicative (http://localhost:8080/angular/angular.js:6883:16)
at additive (http://localhost:8080/angular/angular.js:6874:16)
at relational (http://localhost:8080/angular/angular.js:6865:16)
at equality (http://localhost:8080/angular/angular.js:6856:16)
at logicalAND (http://localhost:8080/angular/angular.js:6847:16)
at logicalOR (http://localhost:8080/angular/angular.js:6839:41)
Is there some way to configure AngularJS to show more stacks? If I look at Chrome console, I can see more stack, and get the filename, but not in the exception handler.
Even if I change the Error limit I cannot see the original file:
Error.stackTraceLimit = Infinity;
1 Use a debugger, instead of Chrome console
Google Chrome provides a debugger that helps JS programmers to find bugs and problematic code.
As the complexity of JavaScript applications increase, developers need
powerful debugging tools to help quickly discover the cause of a
issue and fix it efficiently. The Chrome DevTools include several
useful tools to help make debugging JavaScript less painful.
You can try putting some breakpoints wherever you want (try to detect the problematic lines/ methods).
See the official documentation here: Google Chrome Debugger
2 Use a browser extension
Many plugins like ng-inspector or AngularJS Batarang helps you to print the status of your AngularJS program (controller instances, variable names/values, and scopes).
3 Use $log service (console.log wrapper)
The AngularJS $log service provides a simple resource to print the status of your variables in the browser console (if present).
Simple service for logging. Default implementation safely writes the
message into the browser's console (if present).
The main purpose of this service is to simplify debugging and
troubleshooting.
The default is to log debug messages. You can use
ng.$logProvider#debugEnabled to change this. AngularJS $log service
helps you to debug your program.
From my point of view, a good AngularJS debug includes the combination of all the above solutions.
I hope it is useful for you.
When making a call with the $http service, if the user navigates away from the page while the call is still in progress, it seems the HTTP request is aborted and the promise calls its error() handler. However, I can't seem to figure out how to detect when this error is triggered by an actual problem getting a response from the remote server (server down, network down, timeout, etc), versus when the request is simply cancelled because the user navigated. Both cases appear to pass in the same virtually empty response state arguments to the error handler. (data is empty, status is 0, etc).
I considered using a beforeUnload event handler to detect navigation and assume any error encountered after that event should be ignored, however, this event is not supported in mobile Safari and perhaps other browsers, so it's a not a reliable solution.
This seems like it would be a common issue - how are folks generally dealing with it?
HTML5 provides a convenient History API to deal with this kind of situation. However it varies from browser to browser. In order to ensure (up to a point) cross-browser compatibility I'd recommend you to use the library History.js.
The library provides a useful event you can handle: statechange
For your use case you could warn the user that a request has been initiated and respond to that action accordingly.
https://github.com/browserstate/History.js/
From the /posts/edit-view I'm submitting a form to the action addCategory in my Post controller.
The action does all the work it has to do, and subsequently calls $this->redirect($this->referer());.
At first sight my app works fine, but I encountered some hickups when moving to a production server. Monitoring the calls in Firebug I see that the action acually returns a 302 Found but the 'Response' is Failed to load source for: http://localhost/xps/posts/addCategory.
This happens on both dev en production servers, only on the production server it makes the redirect flow fail. On both servers the controller actions are executed well: category is added.
Removing all the code in the action results in the same failure. Removing the redirect removes the failure, but that's not getting me anywhere.
A second (though maybe irrelevant) irregularity is that the submit method of the form is identified as PUT in Firebug although I explicitly set it to POST in Cake.
I recently switched from CakePHP 1.3.4 to 1.3.6, but reversing does not change the behavior
I use the RequestHandler, Session and Auth components and call parent::beforeFilter() in beforeFilter().
I also found the following thread http://cakephp.1045679.n5.nabble.com/puzzle-over-activity-td1260972.html It suggests to remove $this->Auth->authorize = 'controller'; but I don't have that stated anywhere anyway.
Does anyone have an idea where to look next?
Just a guess, but if you are using Security component, it might cause problems. Also, sometimes when using the ajax and sessions it can cause problems. Maybe if the page requires sessions, you could try it without sessions and see if it works.
Ok, I found it.
The Failed to load source is still there but is not the cause of failure.
In one of my Behaviors I had a space after ?> which messed up the headers, which made me look into the wrong detail.