Re: [jaxrs-dev] New Exception Handling Use-Case

[Rebecca Searls <rsearls@xxxxxxxxxx>]

Ok, I see now how I can access the cause via the getCause method.

I was not aware that value was always set by default.

I see that we no longer need an UnhandlerException. 

Thanks for the info.

On Tue, Oct 23, 2018 at 3:33 PM Santiago Pericas-Geertsen <santiago.pericasgeertsen@xxxxxxxxxx> wrote:

 I don’t follow, you can always access the exception type at runtime (and every Throwable provides a cause). Perhaps you can provide an example that shows the advantage/simplification of using your approach.

— Santiago

On Oct 23, 2018, at 2:06 PM, Rebecca Searls <rsearls@xxxxxxxxxx> wrote:

The problem with that is that the mapper has no access to the original
exception type it only has access to the class type defined in the
ExceptionMapper.  This does not allow the mapper to truly evaluate
the original cause.  The UnHandledException class provides the means
to hand the root level exception to the user code for evaluation.

On Tue, Oct 23, 2018 at 9:56 AM Santiago Pericas-Geertsen <santiago.pericasgeertsen@xxxxxxxxxx> wrote:

Rebecca,

 I understand the issue with using container-specific exception types, that is clearly a very old statement about JAX-WS and Servlets. However, the statement includes the pre-condition “that have not been mapped”.

 So why not map them using some base exception type? Mappers are selected based on type distance, so it should not affect other, more specific mappers. Perhaps I’m missing something about the use case.

— Santiago

On Oct 22, 2018, at 12:46 PM, Rebecca Searls <rsearls@xxxxxxxxxx> wrote:

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

_______________________________________________
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