I do not see why we shall prevent subclassing? What problem would that solve? It restricts possible use cases where still a product-specific distiction is wanted. -Markus From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of Rebecca Searls
Sent: Montag, 22. Oktober 2018 19:50
To: jaxrs-dev@xxxxxxxxxxx
Subject: Re: [jaxrs-dev] New Exception Handling Use-Case
I would suggest a class something like this. Mark the class final so no subclasses
can be made. The key input parameter is Throwable. This allows the container
to provide any exception.
public final class UnhandledException extends RuntimeException {
public UnhandledException(final String s, final Throwable throwable) {
super(s, throwable);
}
public UnhandledException(final Throwable throwable){
super(throwable);
}
}
Add a rule to section 3.3.4 something like the following.
If there is an ExceptionMapper<UnhandledException> register by the user
for any checked, unchecked, error or throwable that have not been mapped
or are handled, allow the user's ExceptionMapper<UnhandledException> to
process the exception. If the user's mapper returns NULL, continue processing
the exception as defined in rule 3 and 4 otherwise return the use's Response
object.
So your proposal would be that the spec shall define a generic exception that all implementations MUST throw instead? -Markus
There is a use-case where the user wants the opportunity to return a Response
object for an exception the jax-rs container does not handle (see spec section
3.3.4 Exceptions). List item 4 in section 3.3.4 states, "Checked exceptions
and throwables that have not been mapped and cannot be thrown directly MUST be
wrapped in a container-specific exception ..." This is not helpful to the user
because such exceptions are container implementation specific. It does not
define a standard class(s) for which a user can provide a ExceptionMapper provider
to evaluation unhandled exceptions.
It is asked that additions be made to the spec to handle this scenario.
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
|
