Bz 62324

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

Bz 62324

Gintautas Grigelionis
I was advised to solicit opinions regarding the change introduced as a fix
for the abovementioned issue. It concerns how an event that has both a
message and an exception is logged.

Namely, a stack trace of the exception is logged (in debug mode only)
without any separator from the preceding message. While it seems that the
idea is that the stack trace should be presented as a continuation of the
message, IMO it would require a specially formatted message or, well, some
separator to be visually consistent.

So the question is whether there is better solution than the one currently
proposed?

Thanks,
Gintas
Reply | Threaded
Open this post in threaded view
|

Re: Bz 62324

Jaikiran Pai
For easy reference, the bug in discussion is this one
https://bz.apache.org/bugzilla/show_bug.cgi?id=62324


On 09/06/18 12:38 AM, Gintautas Grigelionis wrote:
> Namely, a stack trace of the exception is logged (in debug mode only)
> without any separator from the preceding message. While it seems that the
> idea is that the stack trace should be presented as a continuation of the
> message, IMO it would require a specially formatted message or, well, some
> separator to be visually consistent.
>
> So the question is whether there is better solution than the one currently
> proposed?
I saw a commit that was made linking to this bug
https://github.com/apache/ant/commit/69a3f1c1577ef0cf43d2a934a109cb0843c5b754.
Is that the proposed solution?

I haven't investigated the issue myself, but I can't relate that commit
as a solution to what's being discussed in that bug. If I understand it
correctly, the commit seems to be now using the exception class' simple
name (which by the way can be obtained by getClass().getSimpleName()
instead of substring substitutions) and printing a newline and the
exception class simple name and then follows it with the complete
stacktrace. Earlier, before this commit, it used to print just the
stacktrace. I don't see how this change would solve what's being
discussed in that bugzilla.

If this isn't the proposed solution, is there some other place I can
read up on what's being proposed?


-Jaikiran



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

Reply | Threaded
Open this post in threaded view
|

Re: Bz 62324

Gintautas Grigelionis
2018-06-09 13:31 GMT+02:00 Jaikiran Pai <[hidden email]>:

> For easy reference, the bug in discussion is this one
> https://bz.apache.org/bugzilla/show_bug.cgi?id=62324
>
>
> On 09/06/18 12:38 AM, Gintautas Grigelionis wrote:
>
>> Namely, a stack trace of the exception is logged (in debug mode only)
>> without any separator from the preceding message. While it seems that the
>> idea is that the stack trace should be presented as a continuation of the
>> message, IMO it would require a specially formatted message or, well, some
>> separator to be visually consistent.
>>
>> So the question is whether there is better solution than the one currently
>> proposed?
>>
> I saw a commit that was made linking to this bug
> https://github.com/apache/ant/commit/69a3f1c1577ef0cf43d2a93
> 4a109cb0843c5b754. Is that the proposed solution?
>
> I haven't investigated the issue myself, but I can't relate that commit as
> a solution to what's being discussed in that bug. If I understand it
> correctly, the commit seems to be now using the exception class' simple
> name (which by the way can be obtained by getClass().getSimpleName()
> instead of substring substitutions) and printing a newline and the
> exception class simple name and then follows it with the complete
> stacktrace. Earlier, before this commit, it used to print just the
> stacktrace. I don't see how this change would solve what's being discussed
> in that bugzilla.
>
> If this isn't the proposed solution, is there some other place I can read
> up on what's being proposed?
>
>
> -Jaikiran
>

Thanks for review, Jaikiran. You're correct, that is the proposed solution,
adding a separator
(a newline followed by an exception name for clarity -- mind that exception
is logged only in debug mode).

Gintas
Reply | Threaded
Open this post in threaded view
|

Re: Bz 62324

Jaikiran Pai

On 09/06/18 5:22 PM, Gintautas Grigelionis wrote:
>
> Thanks for review, Jaikiran. You're correct, that is the proposed solution,
> adding a separator
> (a newline followed by an exception name for clarity -- mind that exception
> is logged only in debug mode).
The exception class name would already be part of the stacktrace anyway,
so IMO, that wouldn't be of much use. Plus the bugzilla
description/comments state that the thing that's being logged twice is a
message (is it the message from the exception class?). So even with this
change, it will still end up being logged twice right?

By the way, is this issue specific to the delete task?

-Jaikiran

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

Reply | Threaded
Open this post in threaded view
|

Re: Bz 62324

Gintautas Grigelionis
2018-06-09 13:56 GMT+02:00 Jaikiran Pai <[hidden email]>:

>
> On 09/06/18 5:22 PM, Gintautas Grigelionis wrote:
>
>>
>> Thanks for review, Jaikiran. You're correct, that is the proposed
>> solution,
>> adding a separator
>> (a newline followed by an exception name for clarity -- mind that
>> exception
>> is logged only in debug mode).
>>
> The exception class name would already be part of the stacktrace anyway,
> so IMO, that wouldn't be of much use. Plus the bugzilla
> description/comments state that the thing that's being logged twice is a
> message (is it the message from the exception class?). So even with this
> change, it will still end up being logged twice right?
>

Yes, but the double logging only occurs in debug mode AND when the message
is encapsulated in the exception which is added to the same event.

By the way, is this issue specific to the delete task?
>

I didn't investigate, because it is not easy to figure out if a task
creates an event which contains a message both per se and encapsulated in
an exception.

Gintas