FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

FULL OPERATING SYSTEM VERSION :
ANY THAT RUNS JDK1.4+


EXTRA RELEVANT SYSTEM CONFIGURATION :
ANY JDK 1.4+


A DESCRIPTION OF THE PROBLEM :
version 1.4 changed implementation of Throwable.printStackTrace to
print chained exception

however currently it may prints trucated stack trace for chained
exceptions and it is not acceptable for several classes
of apllications like programming with RMI or EJB

instead it should be an optional feature disabled by default!

here is an exampe that shows that information provided by
printStackTrace is almost useless as important stack trace
details of remote exception were truncated after first two lines!

	Exception in thread "main" java.lang.reflect.UndeclaredThrowableException
		at $Proxy0.requestMessages(Unknown Source)
		at SimpleMessageMonitor.main(SimpleMessageMonitor.java:60)
	Caused by: soaprmi.RemoteException: IO Exception; nested exception is:
		java.net.SocketException: Connection reset by peer: JVM_recv in socket input
stream read
		at
soaprmi.soaprpc.HttpSocketSoapInvocationHandler.invokeTransport(HttpSocketSoapInvocationHandler.
j
ava:141)
		at soaprmi.soaprpc.SoapDynamicStub.invoke(SoapDynamicStub.java:120)
		... 2 more


REGRESSION.  Last worked in version 1.4

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.this behavior is now part of JavaDoc with full description specifying this behavior ...

http://java.sun.com/j2se/1.4.1/docs/api/java/lang/Throwable.html#printStackTrace()

EXPECTED VERSUS ACTUAL BEHAVIOR :
expected is full stacktrace that is crucial for debugging (for example in case of distributed apps using
RMI)

ERROR MESSAGES/STACK TRACES THAT OCCUR :
it prints 		... X more for example
		... 2 more
instead of all remaining exceptins

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER WORKAROUND :
overwrite in your exception class method printStackTrace

however does not work if any exception in chained list
of exceptions is one of standard java library exception
(Review ID: 166706) 
======================================================================

N/A

A careful reading of the spec indicates that the ellipsis never omits any stack frames that aren't printed elsewhere in the stack trace.  The relevant prose is reproduced below:

"Note the presence of lines containing the characters "...". These lines indicate that the remainder of the stack trace for this exception matches the indicated number of frames from the bottom of the stack trace of the exception that was caused by this exception (the "enclosing" exception). This shorthand can greatly reduce the length of the output in the common case where a wrapped exception is thrown from same method as the "causative exception" is caught."

In other words, the use of ellipses reduce the output volume from quadratic to linear *without omitting any information*.

  xxxxx@xxxxx   2003-06-19

This bug should be fixed as soon as possible. Normally the
source of the error is exactly in the truncated part!! And
normally these exceptions are of type RemoteException - so
the workaround does not work.

Amen!  Nice idea, bad execution.

Nested exceptions are great.  Recursive stack traces are 
great.  Truncating them so they don't scroll up forever is a 
worthy try.  But the algorithm by which an exception decides 
exactly where to truncate is inscrutable, and it often guesses 
wrong.  

One recent example:  I had a nested NullPointerException 
inside an accessor.  The printed stack trace aggressively 
truncated this trace so all I saw was the line inside the 
accessor where the null pointer was dereferenced, followed 
by "...42 more".  This did not provide me with any context as 
to where the null pointer was *set* in the first place.

And they're not always remote exceptions!  I get them a lot 
in servlet development, since api exceptions get wrapped in 
library exceptions get wrapped in servlet exceptions.  

In fact, this whole Pandora's Box was opened when James 
Gosling added checked exceptions to the language.  Is there 
a bug report for making checked exceptions optional?  I'm not 
kidding: the VM just understands exceptions; it's only the 
Java compiler that forces us to declare, nest or swallow 
exceptions (when the natural action should be to merely pass 
them through).

ecl207
there is no way that is is only affecting 4 people.  i have been 
nearly randomly placing println statements in my code trying 
to zero in on where the error is occuring.  i think this is pretty 
ridiculous.  as umxwgm said the truncation tends to be in 
exactly the part of the stack trace that i need.  particularly in 
rmi systems.  sun get on this, please

I also have the same problem, 4 years after it was reported here. Many libraries put an exception in an exception in an exception (e.g., IOException is put in a MyLibraryException put in a MyApplicationException) and when you print out this exception, the most important lines - what generated the original IOEXception - get truncated, and you only get the useless  line numbers where IOException was wrapped in a MyLibraryException and rethrown, and so on...