Actually I simply have a different view on the words MUST and MUST NOT: I do not know any good reason why someone should want to subclass UnhandledException but I can imagine that some implementors might want to do it. For example, they can simply make it the parent of their already existent ProprietaryInternalUnhandledException so the internal interfaces all stay untouched. I just do not see any good reason for not subclassing it. Unless there is a real need for prohibiting subclassing, I would abstaint from making it `final`. It simply opens room in case someone later comes up with a good reason for subclassing. Do you want to provide a PR or shall I do it? -Markus From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@xxxxxxxxxxx] On Behalf Of Rebecca Searls
Sent: Montag, 22. Oktober 2018 22:12
To: jaxrs-dev@xxxxxxxxxxx
Subject: Re: [jaxrs-dev] New Exception Handling Use-Case It seems to me allowing subclassing of UnhandledException would
defeat the purpose of providing the user a consistent means of getting
access to an unknown exception across container providers.
Why would the container want to declare one or more classes that subclass
UnhandledException. By handing the exception to the user the container
is indicating it has not identified the exception and must take rule 3 or 4
action.
I suppose the spec could allow the container to subClass UnhandledException.
If the user wanted to have consistent handling behavior across all
container providers he could provide ExceptionMapper<UnhandledException>. If
he wanted to be more closely tied to a specific container provider he could
provide a mapper of the container's specific subclass(s).
What scenario are you thinking of where subclassing of this exception would
be desired? 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
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
_______________________________________________
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
|
