[lang] ExceptionUtils

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[lang] ExceptionUtils

Zheng Xie
Hi.

I have found the design of three root cause related methods inconsistent
when the input Throwable does not wrap up another Throwable.

These three methods are

   1. getRootCause(Throwable t)
   2. getRootCauseMessage(Throwable t)
   3. getRootCauseStackTrace(Throwable t)


When the input t has no lower level cause:

   - the first method returns null;
   - the second method returns the message of t, which means the input t is
   considered as the root cause in this method;
   - the third method returns the stack trace of t, which also means this
   method considers t as the root cause.

Therefore, I consider the design of the first method is not consistent with
the second and the third.

I usually write a function myself to get the root cause of an exception;
and it makes much better sense to me the root cause of a Throwable is
itself if no more lower level cause exists.

A request: change the first method to return t itself when there is no more
'causes'.


tigger






In
The 'getRootCause(Throwable t)' method returns null if the parameter t has
no next level cause.
Reply | Threaded
Open this post in threaded view
|

Re: [lang] ExceptionUtils

Benedikt Ritter-4
Hello,

> Am 06.10.2017 um 17:18 schrieb Zheng Xie <[hidden email]>:
>
> Hi.
>
> I have found the design of three root cause related methods inconsistent
> when the input Throwable does not wrap up another Throwable.
>
> These three methods are
>
>   1. getRootCause(Throwable t)
>   2. getRootCauseMessage(Throwable t)
>   3. getRootCauseStackTrace(Throwable t)
>
>
> When the input t has no lower level cause:
>
>   - the first method returns null;
>   - the second method returns the message of t, which means the input t is
>   considered as the root cause in this method;
>   - the third method returns the stack trace of t, which also means this
>   method considers t as the root cause.
>
> Therefore, I consider the design of the first method is not consistent with
> the second and the third.
>
> I usually write a function myself to get the root cause of an exception;
> and it makes much better sense to me the root cause of a Throwable is
> itself if no more lower level cause exists.
>
> A request: change the first method to return t itself when there is no more
> 'causes‘.

Makes sense to me. Why don’t you create a pull request to fix this?

Regards,
Benedikt

>
>
> tigger
>
>
>
>
>
>
> In
> The 'getRootCause(Throwable t)' method returns null if the parameter t has
> no next level cause.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] ExceptionUtils

Pascal Schumacher
Am 08.10.2017 um 15:42 schrieb Benedikt Ritter:

> Am 06.10.2017 um 17:18 schrieb Zheng Xie <[hidden email]>:
>> Hi.
>>
>> I have found the design of three root cause related methods inconsistent
>> when the input Throwable does not wrap up another Throwable.
>>
>> These three methods are
>>
>>    1. getRootCause(Throwable t)
>>    2. getRootCauseMessage(Throwable t)
>>    3. getRootCauseStackTrace(Throwable t)
>>
>>
>> When the input t has no lower level cause:
>>
>>    - the first method returns null;
>>    - the second method returns the message of t, which means the input t is
>>    considered as the root cause in this method;
>>    - the third method returns the stack trace of t, which also means this
>>    method considers t as the root cause.
>>
>> Therefore, I consider the design of the first method is not consistent with
>> the second and the third.
>>
>> I usually write a function myself to get the root cause of an exception;
>> and it makes much better sense to me the root cause of a Throwable is
>> itself if no more lower level cause exists.
>>
>> A request: change the first method to return t itself when there is no more
>> 'causes‘.
> Makes sense to me. Why don’t you create a pull request to fix this?

+1, pull request with unit test(s) welcome

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]