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

Bug 367773

Summary:	The JEE_COMPATIBILITY mode is missing central exceptions handling
Product:	[RT] RAP	Reporter:	Edin Edin <dedagic>
Component:	RWT	Assignee:	Project Inbox <rap-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	enhancement
Priority:	P2	CC:	mknauer, ruediger.herrmann
Version:	1.5
Target Milestone:	2.1 M1
Hardware:	All
OS:	All
Whiteboard:	plan-version=2.0 plan-theme=api plan-status=proposed

Description Edin Edin

2012-01-03 11:09:54 EST

Build Identifier: RAP 1.5.0.M3

The missing of possibility to cetrally handle exceptions, every unexcpected exception causes the application chrash when running in JEE_COMPATIBILTY modus. I posibility to centrally handle those exceptions would give the user the posibility to give feedback about the chrash and to continue to work with the application. 

Reproducible: Always

Comment 1 Ralf Sternberg

2012-12-05 04:20:44 EST

*** Bug 395677 has been marked as a duplicate of this bug. ***

Comment 2 Ralf Sternberg

2012-12-05 04:21:37 EST

Rüdigers points from bug 395677:

I suggest to provide API to register an exception handler. There remain some questions though:
* where should the exception handler be registered, ApplicationConfiguration.setExceptionHandler()?
* what should be the scope of the exception handler, one per session, one per application?
* what about SWT mode, would the usual JFace exception handler interfere with the new 'outer' exception handler?
* should there be a default exception handler?
* what exceptions should be passed to the exception handler, Throwable or Exception?

Comment 3 Ralf Sternberg

2012-12-20 08:13:37 EST

(In reply to comment #2)

In an offline discussion, we agreed on the following:

> * where should the exception handler be registered,
> ApplicationConfiguration.setExceptionHandler()?

Yes, Application.setExceptionHandler().

> * what should be the scope of the exception handler, one per session, one per
> application?

Since it's set on the application, it has application scope. If needed, an implementation can access the UISession when handling exceptions.

> * what about SWT mode, would the usual JFace exception handler interfere with
> the new 'outer' exception handler?

Can't recall what we discussed. But I think it should not interfere. The JFace exception handler would handle exceptions first.

> * should there be a default exception handler?

No, the default would be to throw all exceptions, resulting in HTTP 500, as it is the case today.

> * what exceptions should be passed to the exception handler, Throwable or
> Exception?

Throwable, to give an exception handler the chance to log Errors, too. But errors should be re-thrown after the handler is finished, so an exception handler cannot "swallow" exceptions.

The exceptions should be catched in Display.readAndDispatch().
So, should we wrap the readAndDispatch loop in ProcessAction?

Comment 4 Rüdiger Herrmann

2013-02-22 13:12:58 EST

Implemented exception handler as described in comment #2. One issue that hasn't been mentioned before is exceptions that occur within the exception handler. They are not currently not handled in any particular way and thus conceal the original exception.
The code is available in branch features/exception-handler. If there are no objections I'll merge the changes into master.

Comment 5 Ralf Sternberg

2013-02-25 10:52:10 EST

Looks very good to me. I think it's fair not to handle exceptions that happen in the exception handler.  If the exception handler fails, there's nothing we can do.
Merged into master. Thanks, Rüdiger!