[logback-dev] [JIRA] Issue Comment Edited: (LBCLASSIC-46) ThrowableInformation should keep the Throwable cause hierarchy intact.

[Joern Huxhorn (JIRA)]

    [ http://jira.qos.ch/browse/LBCLASSIC-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=10835#action_10835 ] 

Joern Huxhorn edited comment on LBCLASSIC-46 at 10/29/08 11:06 AM:
-------------------------------------------------------------------

After checking a bit of source, I think that this probably isn't exactly comparable to LBCLASSIC-72 :p

Concerning ThrowableProxy i'd suggest the following structure:

class ThrowableProxy
{
String throwableClassName;
String message;
StackTraceElementProxy[] stackTrace;
ThrowableProxy cause;
transient String stringRep;
}

The only downside would be that the "... x common frames omitted" message wouldn't be possible anymore. The question is, is it really necessary?

I'd also suggest to create the string representation lazily on demand. I guess that we could save quite a big amount of time by lazy creation of string representations (in both ThrowableProxy, StackTraceElementProxy and also in case of LoggingEvent.getFormattedMessage(), see also LBCLASSIC-45 ) when needed instead of, like it is right now, during creation of the logging event itself. It's also leaner in case of serialization.


      was (Author: jhuxhorn):
    After checking a bit of source, I think that this probably isn't exactly comparable to LBCLASSIC-72 :p

Concerning ThrowableProxy i'd suggest the following structure:

class ThrowableProxy
{
String throwableClassName;
String message;
StackTraceElementProxy[] stackTrace;
ThrowableProxy cause;
transient String stringRep;
}

The only downside would be that the "... x common frames omitted" message wouldn't be possible anymore. The question is, is it really necessary?

I'd also suggest to create the string representation lazily on demand. I guess that we could save quite a big amount of time by lazy creation of string representations (in both ThrowableProxy, StackTraceElementProxy and also in case of LoggingEvent.getFormattedMessage()) when needed instead of, like it is right now, during creation of the logging event itself. It's also leaner in case of serialization.

  
> ThrowableInformation should keep the Throwable cause hierarchy intact.
> ----------------------------------------------------------------------
>
>                 Key: LBCLASSIC-46
>                 URL: http://jira.qos.ch/browse/LBCLASSIC-46
>             Project: logback-classic
>          Issue Type: Improvement
>          Components: Other
>    Affects Versions: unspecified
>         Environment: Operating System: All
> Platform: All
>            Reporter: Joern Huxhorn
>            Assignee: Logback dev list
>            Priority: Minor
>
> Instead of a String representation of the whole Throwable stack trace incl. cause ThrowableInformation should instead look like this:
> public class ThrowableInformation implements Serializable
> {
>   String throwableClassName;
>   String message;
>   StackTraceElement[] stackTrace;
>   ThrowableInformation cause;
> }
> I omitted get/set and private in this example.
> StackTraceElement is perfectly Serializable and did also receive a public c'tor in Java 5 so I guess that the current ThrowableInformation is more or less a relict of log4j which had to stay compatible with older Java versions.
> You could obviously keep the getThrowableStrRep() method for compatibility.
> This bug is somewhat related to LBCLASSIC-45 because I think that ThrowableInformation should also, as LoggingEvent, be just a dumb data container with no real logic.
> The logic to extract the relevant StackTraceElements should IMHO be moved either into Logger or into a static factory method of ThrowableInformation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira