On Fri, Sep 3, 2010 at 12:49 PM, Paul Sandoz <Paul.Sandoz_at_oracle.com> wrote:
>
> On Sep 3, 2010, at 11:23 AM, Alexandru Popescu ☀ wrote:
>
>> On Thu, Sep 2, 2010 at 4:11 PM, Paul Sandoz <Paul.Sandoz_at_oracle.com>
>> wrote:
>>>
>>> On Sep 1, 2010, at 7:36 PM, DaHoopster wrote:
>>>
>>>>
>>>> Hi Alex,
>>>>
>>>> Thanks for the reply. I like your solution but what I need is a really
>>>> simple catch-all to catch all runtime exceptions so that a meaningful
>>>> XML
>>>> is
>>>> returned instead of the default HTML error page. I think I will have an
>>>> ExceptionMapper that maps to RuntimeException.
>>>>
>>>
>>> It may be prudent to map Throwable if you need a catch any runtime
>>> exceptions and any checked exceptions thrown by the application.
>>>
>>> Paul.
>>
>> That's already included in my proposed solution ;-). The ugliest thing
>> in a web app/service is to serve the client a stupid stack trace.
>>
>
> Indeed, the only time i find such a thing useful is for a "debug" mode.
>
> I have been wondering what to do there, i thought about using Jersey's
> tracing mechanism to include the stack trace as a trace header, but that
> might make some clients barf having to handle headers with too many CR/LF.
> The other solution i thought about was to provide a URI to where the
> exception stack trace can be obtained. Basically Jersey would provide a
> simple resource where such exception stack traces are cached in memory. In
> fact one could easily add such support as part of the exception mapping
> proposal without having to anything specific to Jersey itself.
>
I would take a step back and consider when is it useful to have access
to a stack trace. I do see a couple of scenarios:
1. I'm developing/testing my application => I do have immediate access
to better mechanisms to find these out
2. A production app is failing for a scenario/user/etc.
I do think that's the only scenario in which I'd need such a stack
trace. But having it without the execution content will not offer me
more details then I could gather from consulting a log file.
So, while I think it is an interesting concept, the benefits are
minimal and you shouldn't bother too much.
:- alex
> Paul.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>