Papyrus Issue #390

[eposse]

This pull request introduces a custom error handler to deal with "undesirable exceptions" as described in Issue #390.

It provides a new status handler called a "FilteringStatusHandler", associated with the new Papyrus-CX product, overriding the default handler.

The new filtering status handler contains a list of "undesirable exceptions" (registered via a new extension point described below). Whenever an exception is thrown and the status handler is triggered (its 'handle' method is invoked), it determines if the cause of the exception matches one of the undesirable exceptions, and if this is the case, it simply logs it and returns, inhibiting any handling by the standard error handler, including pop-ups. Otherwise, if it doesn't match any of the undesirable exceptions registered, it delegates to the standard error handler.

The filtering status handler goes through the exception's "caused-by" chain, and for each exception in the chain it tests whether it is an instance of an undesirable exception, and if so, it goes through the elements of its stack trace to see if the stack trace element has a class name and method name that matches the regular expression of the corresponding undesirable exception, up-to the maximum depth registered for that exception.

The new extension point used to register undesirableExceptions is called "com.zeligsoft.domain.dds4ccm.ui.errorhandlers.undesirableExceptions) and allows to register a sequence of exceptions. The extension must provide four fields:

1) exceptionClass: a subclass of java.lang.Throwable, 2) originClassNamePattern: a regular expression describing the fully-qualified name(s) of class(es) where the exception might originate, 3) originMethodNamePattern: a regular expression describing the name(s) of class(es) where the exception might originate, 4) maximumDepth: an Integer, the maximum depth to look for the class name and method name in the stack trace of an exception

If no originClassNamePattern is provided, the regular expression .* is assumed as default, i.e. matches any class name. If no originMethodNamePattern is provided, the regular expression .* is assumed as default, i.e. matches any method name. If no maximumDepth is provided, the stack trace length is assumed as default.

[J17359]

@eposse is this meant to merge AFTER the new Papyrus product pull request ?

[eposse]

@J17359 Yes. In fact the reason why I proposed to introduce the product was precisely because that is the only way to override the existing status/error handler. Custom status handlers must be associated to a product.

I've tested this commit and it works in avoiding the undesired pop-ups (whose exceptions have been registered as described above), but this should be merged after we are done with the product. I'm still working on the RPM spec for it. It will be a much simpler spec, but it's not working yet. However I hope to have it working by tomorrow.

[eposse]

@elder4p I've incorporated your suggestions and tested it. It works.

I did a couple of things:

• Updated the schema to expect a (fully qualified) class name for the exception
• Extracted the inner class UndesirableException to a top-level class
• Introduced an explicit UndesirableExceptionRegistry, which reads the extension point and provides the list of undesirable exceptions to the FilteringStatusHandler
• Added Java reflection utilities to check if a given class is a subclass or another class, or if it implements a given interface, using the canonical name of the later, to avoid ClassLoader issues. These utilities are very generic, so I put them in com.zeligsoft.base.

Let me know if you want to re-review it. I'll ask Michael and Eric to review it once I've merged the product branch and rebased this one.