I want full stacktrace and not ... 25 more

[John Landon]

Hi,
How do I make jvm spit out everything and not shortening it to ... 25 more?

Thanks.

[Campbell Ritchie]

How about this?

[John Landon]

I know I can get stack trace so........
I need it to spit everything always

[fred rosenberger]

The way I read that API, sometimes the JVM may not give you the full stack trace. That implies to me it may not be possible. I don't know this for a fact, but I'd have to question at this point WHY you need the full thing. Why doesn't the first 5 or 10 give you enough information?

[John Landon]

they do not because it's realy long path to the line with the problem. And in the middle there is reflection.............

[Campbell Ritchie]

I think this is no longer a "beginner's" topic. Moving.

[Mike Simmons]

I believe the "... N more" message generally occurs only when you have a second (or third, fourth, etc) exception which is the cause of the previous exception. The message means that the remaining N lines of the stack trace are exactly the same as the last N lines of the initial stack trace. So these lines don't contain any new info. But if you really want to see that info again, you could re-copy the info from the previous exception.

[John Landon]

no they aren't the same. Thanks though

[Mike Simmons]

Are you sure? How do you know, if you can't actually see the complete stack trace?

Let me show you what I mean with an example:

public class StackTraces {

  public static void main(String[] args) { a(); }

  private static void a() { b(); }

  private static void b() { c(); }

  private static void c() {
    try { d(); }
    catch (Exception e) { throw new RuntimeException("rethrow", e); }
  }

  private static void d() { e(); }

  private static void e() { throw new RuntimeException("cause"); }
}

If I run this from the command line, I get the following stack trace:

Exception in thread "main" java.lang.RuntimeException: rethrow
        at StackTraces.c(StackTraces.java:11)
        at StackTraces.b(StackTraces.java:7)
        at StackTraces.a(StackTraces.java:5)
        at StackTraces.main(StackTraces.java:3)
Caused by: java.lang.RuntimeException: cause
        at StackTraces.e(StackTraces.java:16)
        at StackTraces.d(StackTraces.java:14)
        at StackTraces.c(StackTraces.java:10)
        ... 3 more

I'm saying that this means that the full stack trace would have been:

Exception in thread "main" java.lang.RuntimeException: rethrow
        at StackTraces.c(StackTraces.java:11)
        at StackTraces.b(StackTraces.java:7)
        at StackTraces.a(StackTraces.java:5)
        at StackTraces.main(StackTraces.java:3)
Caused by: java.lang.RuntimeException: cause
        at StackTraces.e(StackTraces.java:16)
        at StackTraces.d(StackTraces.java:14)
        at StackTraces.c(StackTraces.java:10)
        at StackTraces.b(StackTraces.java:7)
        at StackTraces.a(StackTraces.java:5)
        at StackTraces.main(StackTraces.java:3)

I just copied the last three lines of the first stack trace into the second stack trace. if you follow the line numbers carefully, they should make perfect sense. It's just that the last three lines didn't really add any new info that you couldn't have figured out from the original stack trace, so printStackTrace() omitted them. The divergence in stack traces occurred within method c(), where the try/catch/rethrow occurred. But the callers of method c() were the same in each case.

So: you won't see that the lines are duplicated, in the original stack trace - because the duplicated lines have already been omitted. But you can still figure out what they were.

If you still feel this explanation does not apply to your situation: can you show us the complete stack trace, including all "cuased by" nested exceptions? Plus the "... N more" message? That would help us figure out what you're dealing with.

[John Landon]

Thanks a lot for trying to help unfortunatly I don't think I am allowed to give you the stacktrace. And I DO get few caused by.
And I know it doesn't repeat because it doesn't lead me to exact line where exception happened. I follow the trace to get the initial problem but it just cuts. So all I know is in what method it happened. but not in what line

[Mike Simmons]

OK then - instead of using e.printStackTrace(), try this static method:

  public static void printStackTrace(Throwable t) {
    System.out.println(t);
    for (StackTraceElement ste : t.getStackTrace()) {
      System.out.println("\tat " + ste);
    }
    Throwable cause = t.getCause();
    if (cause != null) {
      System.out.print("Caused by ");
      printStackTrace(cause);
    }
  }

[John Landon]

it's out of my reach. It's null pointer exception

[Mike Simmons]

John Landon wrote:And I know it doesn't repeat because it doesn't lead me to exact line where exception happened. I follow the trace to get the initial problem but it just cuts. So all I know is in what method it happened. but not in what line

Well, for an NPE, what you really need is the first "at" line after the last "caused by". Do you have that, at least? In my example above, the equivalent would be the line referring to "(StackTraces.java:16)".

If you're missing even this... well, I can think of one common scenario where this might be considered acceptable. If you're contacting another computer across a network of some sort, and an exception occurs on the other computer, you may receive a truncated stack trace. Or no stack trace at all. In such cases, your best bet may be to look for a log file on the other machine, containing a more complete stack trace.

Another possibility is that the source code you're looking at is not exactly the same as the code that you're running. Perhaps you're using a library in a jar, and there's more than one version available?

[Moojid Hamid]

Here is a modified version of Mike's code, it prints out the full trace. Its easier to show you this in code instead of explaining it.

class StackTraces {     
  public static void main(String[] args) {Thread.setDefaultUncaughtExceptionHandler(new UEH());
  a(); }   
  
  private static void a() { b(); }   
  
  private static void b() { c(); }   
  
  private static void c() {   
    try { d(); }   
    catch (Exception e) { throw new RuntimeException("rethrow", e); }   
  }   
  
  private static void d() { e(); }   
  
  private static void e() { throw new RuntimeException("cause"); }   
}

class UEH implements  Thread.UncaughtExceptionHandler{
	  @Override
	public void uncaughtException(Thread t, Throwable e) {
		StackTraceElement [] ses =e.getStackTrace();
		System.err.println("Exception in thread \""+t.getName()+"\" "+e.toString());
		for(StackTraceElement se : ses ){
			System.err.println("\tat "+se);
		}
		Throwable ec = e.getCause();
		if(ec!=null){
			uncaughtException(t, ec);
		}
	}
}

What we are doing here is catching the Throwable using Thread.setDefaultUncaughtExceptionHandler and instead of printing out the details using printStackTrace we are using getStackTrace and manually printing it out.

[Mike Simmons]

Using Thread.setDefaultUncaughtExceptionHandler is a good idea. However, it will only work if the exception in question is, indeed, uncaught. From what John's said, it sounds like there's a good chance that some other code, somewhere, is catching the exception and printing a truncated error message. If that's the case, the uncaught handler will never get called. Still, it's an idea worth trying.

[John Landon]

Thanks a lot guys. I'll try.