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.
Related
I am creating a socket.io app using angular 2 on the frontend and I am getting a very weird behavior that I have never seen before when working with socket.io. I have no idea if my code is causing the issue or if it is something within the interaction between angular2 and socket.io, but if it is my code, I can't say what code I might need to post.
The mysterious behavior: At first instinct, my process for testing if my sockets connections are working properly is to open up an incognito tab, go to my project site, log in as a different user and see if API requests are emitted properly across the users. However; right now EVERY action that is made on either of the users happens to the other user. EX: if I type into a form one of the clients, the other clients form will get updated with the same information. If I click the forms submit button to post the data in the form, the other clients submit button will be clicked as well. Occasionally, it happens when navigating between states, where the other client will also navigate to the state. The behavior also occurs when logging on to a completely different computer, so imagine it is an issue with how socket.io emits data.
All the clients are connecting and disconnecting appropriately and are getting assigned unique socket ID's.
Turns out, the solution was a bit simpler than I was expecting it to be. I strange behavior occurs through a conflict with npm live-server running at the same time as my socket.io connection. I still cannot explain why the conflict was manifested as this sort of strange behavior, but at least I got it to stop by running the app as an express app serving up the index.html.
If anyone could explain why this might have been happening, I would love to hear.
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.
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/
I'm having an issue where a long synchronous request will freeze Internet Explorer.
Let me explain the context : this is a web application which only supports IE8 and which can only use Synchronous*.
We have a Silverlight component with a save button. When the user presses the button, some information is sent to the server using a synchronous XMLHttpRequest, then some other actions are done client-side in the Silverlight component.
The server-side part includes calculations that will sometime take a while (several minutes).
In short, here is the code (c# silverlight part)
ScriptObject _XMLHttpRequest;
_XMLHttpRequest.Invoke("open", "POST", url, false);
_XMLHttpRequest.Invoke("send", data);
checkResponse(XMLHttpRequest);
doOtherThings();
I know that the server does its work properly because I can see in the verbose logs, the end of the page rendering for the "url" called from Silverlight.
However, in debug mode I can see that I never reach the "checkresponse" line. After calling the "send" line, IE will freeze forever, not unfreezing once the server log shows that "url" has been processed.
Also, I tried to add "_XMLHttpRequest.SetParameter("timeout", 5000)" between the "open" and the "send" lines. IE freezes for 5 seconds, then "checkresponse" and "dootherthings" are executed. Then IE freezes again while server-side calculations are processed and doesn't unfreeze once the server is done with its work.
IE timeout is supposed to be 3 hours (registry key ReceiveTimeout set to 10800000), and I also got rid of IE 2-connexions limit (MaxConnectionsPer1_0Server and MaxConnectionsPerServer set to 20).
Last important information : there is no issue when the server-side part only takes a few seconds instead of several minutes.
Do you know where the freeze could come from (IE bug, XMLHttpRequest bug, something I have done wrong) and how I can avoid this ?
Thank you !
Kévin B
*(while trying to solve my issue with the help of Google I found an incredible amount of "use asynch" and "synch is bad" posts; but I can't do this change in my app. Switching the application, ajax loads, and all server side calculations to asynchronous is a huge work which has been quoted for our client and is a long-term objective. I need a short-term fix for now)
Silverlight virtually requires that everything be done asynchronously. Any long running synchronous process will hang the browser if run on the UI thread. If you never reach the 'checkResponse' line of code it is possible that an unhandled exception was thrown on the previous line, and it is being swallowed. You can check in the dev tools of your browser to see if there are any javascript errors. I am surprised that calling XMLHttpRequest synchronously works at all since I would expect it to lock up the UI thread. But, the solution depends on your definition of async.
You can try:
calling the sync XHR request on a background thread and then marshalling to the UI thread (eg with Dispatcher.BeginInvoke) when you are ready
setting up an XMLHttpRequest wrapper that makes the call in async mode and raises a callback in Silverlight on completion
using HttpClient or WebClient
While these options are async, they don't require your server code to be written any differently (it can stay synchronous). I have seen a web server process a call for over an hour before finally returning a response, at which time the Silverlight app raised a callback. You could even use tools like the TPL await/async, or co-routines available in many mvvm frameworks to make the code appear very procedural/synchronous while still performing its actions asynchronously.
I hope you already solved your issue, but maybe this will be helpful to whomever may come across this post.
I'm trying to deploy a java application to appspot (google appengine). I'm new to java, so bear with me. When I run the application locally from eclipse, it runs fine.
After uploading it to google appspot, I get an error (only in one of the .jsp pages, other .jsp pages work fine). The error log says:
Uncaught exception from servlet
java.lang.ClassCastException: java.lang.ClassCastException cannot be cast to javax.servlet.ServletException
at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:754)
Can somebody shed some light on this issue? What could be wrong in this particular page? If you would like to see the page code, let me know.
It looks like something in your code is throwing an exception that does not derive from ServletException. A handler upstream is catching that exception and (possibly) trying to do something intelligent with it.
There is probably another underlying issue causing the exception to be thrown in the first place, but that might be revealed by seeing first what the exception is.
If you aren't sure where this exception is, try wrapping you entire page handler in a try ... catch block, looking for all Throwable's. When you find one, rethrow it inside of a ServletException:
try {
// handle page request
} catch (Throwable t) {
throw new ServletException(t);
}
This should allow the web server to display the exception so you can continue tracking down the problem. Note that this should probably be temporary code.
Look for instances of javax.servlet.ServletException.class in your WEB-INF/lib.
Contents for servler.jar or servlet.api.jar should be provided bye the container and should not appear in your WAR file.