Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 365436

Summary:	Improve error handling of runtime errors
Product:	[RT] RAP	Reporter:	Beat Schwarzentrub <bsh>
Component:	RWT	Assignee:	Project Inbox <rap-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	enhancement
Priority:	P2	CC:	gmalary, ickefickedicke, ronald.so, zimmermann
Version:	unspecified
Target Milestone:	2.1
Hardware:	All
OS:	All
Whiteboard:

Description Beat Schwarzentrub

2011-12-02 09:32:15 EST

Build Identifier: 1.5.0-N-20111027-0112

Error handling in RAP should be improved to allow for better customization (for example to include a "send this error to the service desk by email" link) and locale-specific display of error messages.

ANALYSIS:

Currently, RAP does not offer one consistent way of handling errors:

Server-side errors
- "Multiple browser-instances or browser-tabs per session are not supported. You may click OK for restarting the session." is localized. Display of message cannot be customized (hard-coded in ErrorHandler.js).
- "The server session timed out. Please click here to restart the session." is localized. Display of message cannot be customized (hard-coded in Display.js).
RAP contains only one localization (the default one, RWTMessages.properties) with messages in English. Further languages have to be added using a fragment.

Client-side errors
- "Request failed. HTTP Status Code: xxx" is hard-coded in Request.js (_handleFailed)
- "The server seems to be temporarily unavailable. Would you like to retry?" is hard-coded in Request.js (_handleConnectionError)
- Certain other error texts are hard-coded in ErrorHandler.js, e.g. the document title "Error Page" or messages for JavaScript errors.

PROPOSED SOLUTION:

Stage 1:
Get rid of hard-coded texts in the org.eclipse.rap.rwt plugin. All text should at least be localizable.

Stage 2:
Allow for "adding a custom error handler".
Ideas:
- Add entries in RWTMessages.properties for all error messages. Allow theming of displayed error messages. Pro: simple. Contra: messages have to be transferred to the browser.
- Allow programmers to extend or replace the file ErrorHandler.js (and of course, make sure, all errors end up here!). Pro: rather flexible. Contra: rather complex.
- Whenever an error occurs, redirect the browser to a special /error servlet, passing an error code to it (or a similar identifier or error object). Pro: Centralized handling of errors, flexible, server infrastructure is available (e.g. write files or send e-mails). Contra: Additional roundtrip needed, complex, does not work when server is down.
- ...

Reproducible: Always

Comment 1 Ralf Sternberg

2012-05-23 07:34:14 EDT

Unfortunately, this didn't make it into 1.5. Will keep this bug high priority anyway, because I believe that not being able to customize these messages can be a blocker for productive deployment.

Comment 2 Ronald So

2012-05-23 14:25:23 EDT

On top of the great comments in this bug, there should be a way to avoid Java exception stack trace to show up in the UI when there is a runtime exception that is not being caught in the code.  An ideal way is to forward the UI to a specific page (or pop a dialog box), show users with a customizable message and suppress the Java exception stack trace.

Not sure if I need to file an additional bug but let me know if you want me to log this comment as a separate enhancement request.

Comment 3 Ronald So

2012-05-23 14:44:17 EDT

I hate when I did this.  I found out right after my comment that ApplicationWorkbenchAdvisor.eventLoopException() handles the runtime exception.  I assume I can code my way to show an error page and suppress the exception stack trace from the UI.  Sorry for the false alarm.

Comment 4 Ralf Sternberg

2013-03-15 07:22:42 EDT

To provide more flexibility for deployments with container-based authentication, I think we should indeed support custom error handlers. For example, when using Form-Authentication in RAP, the container would intercept Ajax requests and return a custom error JSON (see bug 390711). A "session timeout" / "authentication required" error could be handled by the client in different ways, depending on the setup, e.g.

* the client could display a dialog with a reload link
* the client could reload the page, automatically following the redirect to a login page
* the client could display a login form itself and send the credentials to j_security_check
...

Comment 5 Ralf Sternberg

2013-05-24 04:04:16 EDT

As a first step, the error messages have been made translatable. The default texts reside in the message bundle org/eclipse/rap/rwt/internal/RWTMessages.properties in the rwt bundle. Localized message bundles (RWTMessages_xx.properties can be included in a deployment, e.g. in an OSGi fragment. When the RWT locale changes (RWT.setLocale()), the translated error messages on the client are now updated correctly.

What about renaming and moving the message bundle to a public place, e.g. org/eclipse/rap/rwt/client/WebClientMessages.properties?

Comment 6 Ralf Sternberg

2013-11-06 07:58:30 EST

We agreed to keep the WebClientMessages.properties file at the current location.

Theming support of the message box is requested by bug 342140.

I'm closing this bug now. If there's still interest in exchangeable error handlers, please open a new enhancement request. Alternatively, you could simply overwrite the related ErrorHandler.js method in a custom JavaScript.