Is there a way to catch file upload errors when using the FileUpload facility in GWT?
After reading GWT 2.1 Javadoc I have little hope.
It would appear that the GWT Javadoc documentation is somewhat wrong in stating that onSubmitComplete is called upon successful form submission: the callback is triggered even when an error occurs. The getResults() method can be called to watch for null value indicating an error condition.
Related
Is there a way to pass any meaningful message, not “std::exception” to the promise’s fail callback? In the sources I found the following “void FB::variantDeferred::reject(std::exception e) const” specification. It seems when reject is called with any exception derived from std::exception the slicing happens and the right exception’s message is lost. Is there any workaround but to pass error through success callback?
std::exception is simply a base class for creating exceptions in C++. You can use a number of different methods to pass a specific string back; for example, you could throw a std::runtime_error, which accepts a message.
You could also subclass std::exception and provide an implementation of std::exception::what which returns a useful string representation of what you want.
FireBreath 2.0 will use the error message from e.what() when it creates the Error object. You can find this in the code, if you're curious how that works:
NPAPI
ActiveX
FireWyrm (used for Native Messaging)
When I run a Flex/AIR application in debug mode and an error occurs, I see this:
TypeError: Error #1009: Cannot access a property or method of a null object reference.
However when the application has been installed as a release build and the same error happens, I don't see an error message.
Is it possible for my application to either save these types of errors to a log file or email them to me?
I have managed to implement this myself using the UncaughtErrorEvent and airxmail classes.
It was a simple case of adding the UncaughtError event to loaderInfo (within a method which is called by the FlexEvent.APPLICATION_COMPLETE event). Using these two classes, the application emails the runtime errors to me as and when they occur, in release mode only as the UncaughtError event does not fire in debug mode.
If you want to log your uncaught errors you can use the uncaughtError event.
loaderInfo.uncaughtErrorEvents.addEventListener(UncaughtErrorEvent.UNCAUGHT_ERROR,handleGlobalErrors);
function handleGlobalErrors( evt : UncaughtErrorEvent ):void
{
//code that saves error to log or send by email..
evt.preventDefault();
}
You can find more information about this feature here http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/events/UncaughtErrorEvent.html.
Also beware that if you use this in Debug mode all your errors will be caught by the handleGlobalErrors function so keep that in mind.
I'm working on some flash app. Now, to test customer side of it I can use Flash Player debugger version that will save logs and show error messages. When it's deployed on the customer side - they will have a regular Flash Player version which means I will have no access to error messages if errors will happen. So I would like to equip it with some tool that would capture all of my trace messages in code and errors text. As for trace messages that's fairly simple, I just override the function in my code so it sends a POST request with trace message to a logger server, but how can I get a hold of the error message? Is there a known approach to this or some trick that somebody can suggest?
You can install the debug version of flash as your browser's default (in Chrome, you must disable the built-in player), so if you wanted to test user experience and debug, this would be the ideal solution.
However, to answer your question: there's no method for universally catching all errors, and redirecting them (that I know of). You'd have to encapsulate problem code ahead of time with try...catch statements, and send the property back on catch. For example:
try {
this["foo"]();
} catch (e:Error) {
trace(e);
}
In the debug version, the traced value would be TypeError: Error #1006: value is not a function. And while the standard version will only output TypeError: Error #1006, (a notably less descriptive error), what we're missing is any reference to where the error occured. To get this, we need to use Error.getStackTrace() to see the call stack and the line where the error occurred. In debug, this outputs the following:
TypeError: Error #1006: value is not a function.
at Shell_fla::MainTimeline/init()[C:\Projects\shell.as:91
In the standard client, we get a dissapointing null. In short, you cannot get any valuable info from the client versions.
The best advice I can give is to write around your problem code with your own custom error reports. For example, catch IO errors and trace the file it failed to load, or if you're expecting an object.foo, first try if (object.hasOwnProperty("foo")) { // do something } else { trace("foo not found in " + object.name) }. Code defensively.
Cheers,
I've discovered this post on StackOverflow:
How to catch all exceptions in Flex?
It answers my question, strange that I haven't ran into it while I was googling prior to asking.
I’m struggling fully understanding when/how exceptions are thrown in JSF 2.0. I’ve looked for a solution longer than I care to admit. Ultimately, the goal I want to achieve is “handle” an unhandled exceptions. When an exception is thrown, I want to be able to capture information of interest about the exception, and email that to the appropriate site administrators. I’m forcing an error by throwing a new FacesException() in the constructor of one of my backing beans. I had this working great in JSF 1.1 using MyFaces implementation. I was able to get this working by wrapping the Default Lifecycle and simply overriding the execute() and render() methods. I followed this awesome post by Hanspeter to get that working:
"http://insights2jsf.wordpress.com/2009/07/20/using-a-custom-lifecycle-implementation-to-handle-exceptions-in-jsf-1-2/#comment-103"
I am now undergoing a site upgrade to JSF 2.0 using Mojarra’s. And things work great still as long as the exception is thrown/caught in the execute() method, however; the moment I enter the render(), the HttpServletResponse.isCommitted() equals true, and the phase is PhaseId RENDER_RESPONSE which of course means I can’t perform a redirect or forward. I don’t understand what has changed between JSF 1.1 and 2.0 in regards to when/how the response is committed. As I indicated, I had this working perfectly in the 1.1 framework.
After much searching I found that JSF 2.0 provides a great option for exception handling via a Custom ExceptionHandler. I followed Ed Burns’ blog, Dealing Gracefully with ViewExpiredException in JSF2:
"http://weblogs.java.net/blog/edburns/archive/2009/09/03/dealing-gracefully-viewexpiredexception-jsf2"
As Ed indicates there is always the web.xml way by defining the tag and what type of exception/server error code and to what page one wants sent to for the error. This approach works great as long as I’m catching 404 errors. One interesting thing to note about that however, is if I force a 404 error by typing a non-exsitant URL like /myApp/9er the error handler works great, but as soon as I add “.xhtml” extension (i.e. /myApp/9er.xhtml) then the web.xml definition doesn’t handle it.
One thing I noticed Ed was doing that I hadn’t tried was instead of trying to do a HttpServletRespone.sendRedirect(), he is utilizing the Navigationhandler.handleNavigation() to forward the user to the custom error page. Unfortunately, this method didn’t do anything different than what Faclets does with the error by default. Along with that of course, I was unable to do HttpServletResponse.sendRedirect() due to the same problems as mentioned above; response.isCommitted() equals true.
I know this post is getting long so I will make a quick note about trying to use a PhaseListener for the same purposes. I used the following posts as a guide with this route still being unsuccessful:
"http://ovaraksin.blogspot.com/2010/10/global-handling-of-all-unchecked.html" "http://ovaraksin.blogspot.com/2010/10/jsf-ajax-redirect-after-session-timeout.html"
All and all I have the same issues as already mentioned. When this exception is thrown, the response is already in the committed phase, and I’m unable to redirect/forward the user to a standard error page.
I apologize for such a long post, I’m just trying to give as much information as possible to help eliminate ambiguity. Anyone have any ideas/thoughts to a work around, and I’m curious what might be different between JSF 1.1 and 2.0 that would cause the response to be committed as soon as I enter the render() phase of the Lifecycle.
Thanks a ton for any help with this!!!
So this question is actually not just about a custom exception handler (for which JSF 2 has the powerful ExceptionHandlerFactory mechanism), but more about showing the user a custom error page when the response has already been committed.
One universal way to always be able to redirect the user even if the last bit has already been written to the response is using a HttpServletResponse wrapper that buffers headers and content being written to it.
This does have the adverse effect that the user doesn't see the page being build up gradually.
Maybe you can use this technique to only capture the very early response commit that JSF 2.0 seems to do. As soon as render response starts, you emit the headers you buffered till so far and write out the response content directly.
This way you might still be able to redirect the user to a custom error page if the exception occurs before render response.
I have successfully implemented a filter using response wrapper as described above which avoids the response being commited and allows redirection to a custom page even on an exception in the middle of rendering the page.
The response wrapper sets up its own internal PrintWriter on a StringWriter, which is returned by the getWriter method so that the faces output is buffered. In the happy path, the filter subsequently writes the internal StringWriter contents to the actual response. On an exception, the filter redirects to an error jsp which writes to the (as yet uncommitted) response.
For me, the key to avoiding the response getting committed was to intercept the flushBuffer() method (from ServletResponse, not HttpServletResponse), and avoid calling super.flushBuffer(). I suspect that depending on circumstances and as noted above, it might also be necessary to also override some of the other methods, eg the ones that set headers.
How can we handle exceptions in Struts? Please share the sample code.
The following URL should help http://www.objectsource.com/j2eechapters/Ch18-Exception_Handling.htm
Use log4j to log the exceptions,
Never use System.out.println in struts application to catch exceptions, as it is expensive ,
Tutorials for log4j> http://logging.apache.org/log4j/1.2/manual.html
to handle the errors:
in struts project to handle the error objet by using ActionError object and to handle the errors by using ActionErrors object.
for suppose
ActionError ae1=new ActionError("err.one");
ActionError ae2=new ActionError("err.two");
Action Errors aes=new ActionErrors();
aes.add(ae1);
aes.add(ae2);
saveErrors(request,aes);//store the errors object in request object
to handle exception:
1)using try and cach blocks
2)using declarative exception handling technique
to handle the exceptions by using global exceptons tag in struts-config.xml
whenever that exception will be came it executes the gen.jsp page.