Featured White Papers

• Why choose an Open Source BPM?
• 10 FAQs on Business Process Management
• Best Practices for Getting Started with BPM
• Free Your Devs From The Pain Of Java Redeploys
• Increase Velocity 40% by Using JRebel
• What Developers Want: The End of Application Redeploys
• Developer Productivity Report: Java Tools, Tech, Devs, and Data
• Coding with JRebel: Java Forever Changed
• Utilizing Fast Testing to Transform Java Development
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• APIs for Java Programmers: Manage & Convert DOC, XLS, PPT, PDF & More

• Instantly Preview Java Code Changes: JRebel.com

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Some Recipes to Improve Your Google Web Toolkit Development

Experiences, tips and techniques to assist you in creating GWT Web applications.

By Klaus P. Berg, JavaWorld.com, 04/26/07

Page 4 of 6

One thing I recommend to do on the client-side is to provide your own exception handler for any uncaught exceptions using the GWT.setUncaughtExceptionHandler() method. After having caught these kind of exceptions you have several alternatives: GWT.log(message, caught), Debug.println (message_with_stacktrace), when working with Mat Gessel's' Debug class, or - coming closer to JavaScript - Window.alert(message_with_stacktrace), or your own customized error reporting. Figure 3 shows the GWT console output if you do not catch all exceptions.

Figure 3: GWT console output when not catching all exceptions on the client side

Depending on the origin, you will either get "Failure to load module" (if the exception was thrown inside your onModuleLoad() method) or "Uncaught exception escaped", if it has been thrown elsewhere in your client code. Of course, you can click on the error message in the GWT console to get the full stacktrace but I recommend to use the startup sequence shown in listing 1 as a template for your onModuleMoad() method. It makes use of a small DebugUtility class that provides a default client-side error handling that can easily be customized.

On the server-side you have the broad power of the java.util.logging API or of log4j, depending on your personal preferences or on the project's constraints. However, if you do not patch GWT's com.google.gwt.user.server.rpc.RemoteServiceServlet class, for uncaught unchecked exceptions you will only get a hint inside the stacktrace that points to your server-side class that produced the error; for checked exceptions that are covered and reported inside your catch() block, everything is fine.

To give you an idea of what I mean, please look at figure 4 that shows two screenshots of error messages caught in hosted mode with Window.alert (you will get the same messages on your Eclipse console):

• The first alert window contains the original message from the RemoteServiceServlet class pointing to a proxy.

• The second alert window shows the output with the patch mentioned above, pointing to the concrete line of servlet code that forced the error (marked with a blue border).

Figure 4: Server-side exception reporting enhanced

The code presented in listing 2, an addition to the processCall() method of the RemoteServiceServlet class does the magic (my statements are marked as bold).

The only thing to pay attention to is to incorporate the patched class so that it is searched before the original GWT code from gwt-user.jar in your classpath. But note: all this patching will not help you when you call a remote method with a wrong target in your setServiceEntryPoint(GWT.getModuleBaseURL() + "/wrongTarget") method. This can happen, e.g., with copy/paste actions when you tried to "reuse" server access code, but you forgot to adapt the target string constant.

Tip 3: Beware of the GWT Shell's "Refresh" Button Pitfalls

When you start your application in hosted mode, you will see a "Refresh" button in your browser's toolbar. When you press this button, GWT will recompile your modified Java client sources to Java bytecode (as .tmp files in the .gwt.-cache/bytecode directory) and reload your module. You can use this button to shorten your edit-compile-debug cycle, but there are some things you should keep in mind when using this nice feature: