• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

I want full stacktrace and not ... 25 more

 
John Landon
Ranch Hand
Posts: 228
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
How do I make jvm spit out everything and not shortening it to ... 25 more?

Thanks.
 
Campbell Ritchie
Sheriff
Pie
Posts: 49367
62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How about this?
 
John Landon
Ranch Hand
Posts: 228
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I know I can get stack trace so........
I need it to spit everything always
 
fred rosenberger
lowercase baba
Bartender
Posts: 12143
30
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 228
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
they do not because it's realy long path to the line with the problem. And in the middle there is reflection.............
 
Campbell Ritchie
Sheriff
Pie
Posts: 49367
62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think this is no longer a "beginner's" topic. Moving.
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 228
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
no they aren't the same. Thanks though
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:

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

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

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
Ranch Hand
Posts: 228
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK then - instead of using e.printStackTrace(), try this static method:
 
John Landon
Ranch Hand
Posts: 228
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
it's out of my reach. It's null pointer exception
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 120
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.



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
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 228
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks a lot guys. I'll try.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic