JDK-4098246 : custom backtraces
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.1.2,1.1.5,1.2.2,1.3.1
  • Priority: P5
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS:
    generic,solaris_2.5.1,windows_98,windows_nt generic,solaris_2.5.1,windows_98,windows_nt
  • CPU: generic,x86,sparc
  • Submitted: 1997-12-10
  • Updated: 2002-02-01
  • Resolved: 2002-02-01
Related Reports
Duplicate :  
Relates :  
Description

Name: rm29839			Date: 12/09/97


One thing that would be quite useful for me
would be if you could make an exception with
a custom backtrace. For example, if I have
a new subsystem that I want to define, I may
want the stack traces that come out of it to
be more symbolic than simply original source
method, file and line number. For example, if
I'm writing a new interpreter, I might want to
provide source lines from that interpreted
language rather than from the Java VM. Another
example would be if I wanted to make an opaque
subsystem, then I could filter out internal
code details on any exceptions that I pass out
of the subsystem.

The two things that would make this work possible
would be:

1. A method on Throwable to get a structured
backtrace. For example:

   String[] getBacktrace();

which would return a string, in a well-known
format, per line of backtrace. This would make
it easy for intermediate code to manipulate a
stack backtrace for subsequent use.

2. A standard constructor for Throwable that
takes such a structured backtrace to use in
place of the "default" one. For example:

   public Throwable(String detailMessage, 
                    String[] backtrace);

which would use the given backtrace instead
of generating one based on the current dynamic
context. 

Dan Bornstein
###@###.###
(Review ID: 21577)
======================================================================

Name: tb29552			Date: 03/23/2000


java version "1.2.2"
Classic VM (build JDK-1.2.2-W, native threads, symcjit)


Java needs a decent mechanism to access the stack traceback.

So far the only way I know to get at the stack trace from
a Java class is to create a Throwable and parse the String
available therefrom.  This is expensive and unreliable.

There should be a StackTrace class that contains multiple
instances of a StackTraceElement class.  Throwable would
contain an instance of StackTrace.  StackTrace.toString()
would format the entire trace to String in the format that
is currently printed by Throwable.printStackTrace().

Java can make things so easy, but not always!
(Review ID: 102773)
======================================================================

Comments
WORK AROUND Name: rm29839 Date: 12/09/97 There is no workaround. There is currently no way to specify a custom backtrace. ====================================================================== Name: tb29552 Date: 03/23/2000 1) Create a Throwable 2) Call printStackTrace(), passing a StringWriter 3) Parse the StringBuffer filled in by the StringWriter This is very expensive and dependent on the implementation. (Review ID: 102773) ======================================================================
11-06-2004

EVALUATION You are always free to create your own subclasses of Throwable that store any sort of information that you want. That should suffice for writing conventional interpreters. I can see that if you want to call into interpreted code from within compiled Java, however, it would be helpful for the interpreted code to appear on a Java backtrace in terms of the interpreted language rather than in terms of the interpreter's internals. I don't think that mucking around with the backtrace in string form is the right answer, however. william.maddox@Eng 1998-03-02 A "structured backtrace" facility will be added to Merlin in support of the new Assertion facility. The remainder of this RFE (allowing the creator of a Throwable to provide his own backtrace) is a possibility for inclusion in this facility.l joshua.bloch@Eng 2000-04-13
13-04-2000