aspose file tools*
The moose likes Java in General and the fly likes Why no stack overflow? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Why no stack overflow?" Watch "Why no stack overflow?" New topic
Author

Why no stack overflow?

Shalini Srivastav
Ranch Hand

Joined: Jul 21, 2012
Posts: 86

Why it doesn't throw StackOverflowError while below will ?
Tushar Kapila
Ranch Hand

Joined: Dec 23, 2007
Posts: 35

while true only loops endlessly - not recursion. if you made a new object (and references it in an array list or other way then you would run out of memory here too)

where as a fn calling it self is recursion and java makes a new set of local variables etc and adds each function call to the stack - taking up memory....


http://thehungersite.com | http://www.worldcommunitygrid.org/
Shalini Srivastav
Ranch Hand

Joined: Jul 21, 2012
Posts: 86
I haven't any local variable or object in my method,and so far i know after each method call local variables are destroyed from stack and heap.
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4421
    
    8

The virtual machine has to keep track of which methods have been called, so that it can return to them in the right order. There's a limited amount of memory allocated for it to do this in. So you don't have to declare any variables to get a stack overflow - each recursive call will use up some of this space which will not be released until the method returns.
Shalini Srivastav
Ranch Hand

Joined: Jul 21, 2012
Posts: 86

at Errortest.m(Errortest.java:4)
at Errortest.m(Errortest.java:4)
at Errortest.m(Errortest.java:4)
at Errortest.m(Errortest.java:4)
at Errortest.m(Errortest.java:4)
at Errortest.m(Errortest.java:4)

I don't know what is the error ?
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39396
    
  28
Surround the entire code in that main method with a try-catch(Throwable t), and print the class name and message from t.
Don’t catch Throwables or Errors in real life code, and read about this class, too.
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4421
    
    8

Shalini Srivastav wrote:I don't know what is the error ?

That's the stack overflow you've been talking about. You're just missing the start of the message. If you're running in an environment where you can't see the entire message, Campbell's suggestion will do the trick.
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 11406
    
  16

What you really got was something like this:

C:\slop>java Errortest
Exception in thread "main" java.lang.StackOverflowError
at Errortest.m(Errortest.java:4)
at Errortest.m(Errortest.java:4)
at Errortest.m(Errortest.java:4)

<skip about 1000 lines of this same thing over and over>

at Errortest.m(Errortest.java:4)
at Errortest.m(Errortest.java:4)

C:\slop>

most of that probably rolled off the top of your command window. You can redirect it to a file if you want to see it, or just increase the number of lines of history your cmd window keeps.


There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Campbell Ritchie wrote:Don’t catch Throwables or Errors in real life code

I disagree - catching a Throwable specifically so you can log it is an excellent reason to catch a Throwable, even in real life. The idea that this should be avoided is counterproductive. Logging is good. Seeing a clear error message is good.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8008
    
  22

Mike Simmons wrote:Logging is good. Seeing a clear error message is good.

I agree with both of those statements, but catching a Throwable isn't the way to solve it.

First: Logging is only of interest for debugging; there's no guarantee that a user will see anything.
Second: Catching a Throwable goes against all theories of propagation. Furthermore, it's highly likely to make your app very slow indeed.

Just a couple off the top of my head.

Winston


Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Martin Vajsar
Sheriff

Joined: Aug 22, 2010
Posts: 3610
    
  60

Winston Gutkowski wrote:(Catching a Throwable) is highly likely to make your app very slow indeed.

I'd be curious to know the reasoning behind this statement. Catching any exception should slow things down only when the exception actually occurs. Plus, the overhead of an exception is incurred when the exception is created (creating the stack trace and all), the catch clause - unless it does a lot of things itself - should not do that much.

I do not advocate catching Throwable myself, actually. I prefer installing an uncaught exception handler to report/log unexpected exceptions.
James Boswell
Bartender

Joined: Nov 09, 2011
Posts: 1030
    
    5


Logging is only of interest for debugging;


Winston

How about when an unexpected error occurs and the user is presented with a generic "Something unexpected happened" message (as you certainly wouldnt want them to see a stack trace). Wouldnt this be an ideal scenario when the user contacts system support and someone can check a log file to see what happened.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8008
    
  22

Martin Vajsar wrote:I'd be curious to know the reasoning behind this statement...

Because Mike's post appeared to be advocating this as a logging panacaea, which I assume to include cases when the "error" is recoverable; and throwing an Exception is, and probably always will be, very expensive.

Winston
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8008
    
  22

James Boswell wrote:How about when an unexpected error occurs and the user is presented with a generic "Something unexpected happened" message (as you certainly wouldnt want them to see a stack trace).

I hope I covered that by agreeing with both of his initial statements; what I don't agree with is that catching Throwable is the way to solve it. As to "Seeing a clear error message", "clear" is probably in the eye of the beholder; and I reckon Sun/Oracle themselves could do with some better ones.

Winston

Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Winston: Hmmm, I don't buy the "very slow indeed" comment. Can you elaborate?

And "only of interest to debugging" - I suppose, yes. If by "debugging" you mean figuring out what went wrong, based on log files. (As opposed to using a debugger.) But that's pretty important in my experience. If something goes wrong, I want evidence in my log file to explain. Or at least offer clues. Martin has a good point about uncaught exception handlers, but I find it's sometimes nice to log contextual info at the same time, e.g. unknown exception while processing record #1234, etc. I find that easier with a catch.

As for the comment about propagation, I would agree that it's almost always wrong to catch a Throwable, log it, and do nothing else. Chances are good that the system is compromised, and further problems may well be about to occur. And I hate it when people do stuff like this:

Obviously, if an exception occurred here, it makes no sense to proceed with f.callMethod(), as f is null. More generally, any time you catch an exception, you need to consider whether there's any sensible way to recover at the level you've caught it at; if not, maybe you were better off either not caching it, or rethrowing it. This applies to any exception handling, including any catch Throwable.

So, I'm not saying saying one should catch Throwable and do nothing else. It may make perfect sense to catch, log, and rethrow. But the act of catching itself is not automatically wrong.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Winston Gutkowski wrote:
Martin Vajsar wrote:I'd be curious to know the reasoning behind this statement...

Because Mike's post appeared to be advocating this as a logging panacaea, which I assume to include cases when the "error" is recoverable; and throwing an Exception is, and probably always will be, very expensive.n

Hunh? You're imagining things I did not say. If the error was recoverable, it should have been handled by some earlier catch block. I'm just saying catching a Throwable is not automatically a bad thing. And at this point I don't care if it was expensive; I didn't decide to throw it in the first place, and if it's not caught the thread is about to crash anyway; how does logging the event make that worse? It gets a little bit slower, but if it's an Error, so what? Apparently the world is ending anyway. I'm just trying to get a record of what happened.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8008
    
  22

Mike Simmons wrote:As for the comment about propagation, I would agree that it's almost always wrong to catch a Throwable, log it, and do nothing else. Chances are good that the system is compromised...

I guess your experience is different from mine then. I'm much more of a proponent of not catching Exceptions at all unless I have to; I'd far rather simply declare my method as throwing it and let some other method deal with it (hopefully the one that is supposed to) - or it not being dealt with at all.
That's the way to make sure your code is robust.

I have two major exceptions to my "rule": IllegalArgumentException and NullPointerException. Both of those should be dealt with as close to source as possible, and I totally agree with you about "clear error messages".

Winston
Martin Vajsar
Sheriff

Joined: Aug 22, 2010
Posts: 3610
    
  60

How do you deal with IllegalArgumentException and NullPointerException, moreover "as close to the source as possible"? Both are a result of a bug and cannot should not be attempted to recover from. My approach always was to let them bubble all the way up the stack into the log file and then glean from the offending line what went awry. Am I doing it wrong all the years?
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Winston Gutkowski wrote:
Mike Simmons wrote:As for the comment about propagation, I would agree that it's almost always wrong to catch a Throwable, log it, and do nothing else. Chances are good that the system is compromised...

I guess your experience is different from mine then. I'm much more of a proponent of not catching Exceptions at all unless I have to; I'd far rather simply declare my method as throwing it and let some other method deal with it (hopefully the one that is supposed to) - or it not being dealt with at all.
That's the way to make sure your code is robust.

I have two major exceptions to my "rule": IllegalArgumentException and NullPointerException. Both of those should be dealt with as close to source as possible, and I totally agree with you about "clear error messages".

I agree with all you just wrote there; not sure where you disagree with me though. I am not advocating using catch Throwable willy-nilly. I much prefer to let exceptions be thrown from most lower levels. But there are times when I want a backstop; whatever has gone wrong with the current request/record/order/file/whatever that I'm processing, log it and move on, if possible. Even here I would often use catch Exception rather than catch Throwable, unless I'm catching at such a high level that the program is probably about to end anyway.

But I get really tired of people objecting to any use of catch Throwable. And that's why I posted in this thread. Please don't imagine that I do this everywhere in my code. I do it when I have a good reason, and when my usual alternatives do not applyfor some reason. It's a last resort usually. But I believe it's still valid to have, even in production code.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Martin Vajsar wrote:How do you deal with IllegalArgumentException and NullPointerException, moreover "as close to the source as possible"? Both are a result of a bug and cannot should not be attempted to recover from. My approach always was to let them bubble all the way up the stack into the log file and then glean from the offending line what went awry. Am I doing it wrong all the years?

Actually I agree with Martin here too. I somehow read the "deal with as close to the source as possible" as "fix the source".
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8008
    
  22

Martin Vajsar wrote:How do you deal with IllegalArgumentException and NullPointerException, moreover "as close to the source as possible"? Both are a result of a bug and cannot should not be attempted to recover from. My approach always was to let them bubble all the way up the stack into the log file and then glean from the offending line what went awry. Am I doing it wrong all the years?

Dunno (BTW, this is a fun argument - and we don't get too many of those - even though I appear to be outvoted ), but:

First: I hope that you would be throwing IllegalArgumentException yourself; most especially in cases where the code might otherwise throw an NPE, which are hard to track (unless you're one of those rare breeds that can actually glean the reason for an NPE from a simple stack trace).

Second: Catching exceptions before their time (and I can't think of a better way to do it than catching a Throwable) is a surefire path to duplicated code.

Third - NPE's: The bane of every programmer's existence. It's hard, but I always try to prevent them if I can. The next best thing is to catch them as fast as you can, so in cases (and there are some) where I know the cause, I'd much rather catch it and wrap it in a nice, "clear" message that explains the reason.

Come on. Bring it on.

Winston
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8008
    
  22

Mike Simmons wrote:Actually I agree with Martin here too. I somehow read the "deal with as close to the source as possible" as "fix the source".

Ah. You've clearly not worked on systems where the code is NOT under your control...or maybe you just forgot .

Winston
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39396
    
  28
I started off some interesting discussion there
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8008
    
  22

Campbell Ritchie wrote:I started off some interesting discussion there

Yeah. Outvoted old fart as usual, but what the hey....

Winston
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Winston Gutkowski wrote:
Mike Simmons wrote:Actually I agree with Martin here too. I somehow read the "deal with as close to the source as possible" as "fix the source".

Ah. You've clearly not worked on systems where the code is NOT under your control...or maybe you just forgot .

I assume you mean that the code you're calling is not under your control, while the code you're calling from is? And we've already ruled out the possibility that the caller (us) is actually responsible for the null or illegal argument (which is what IAE is for, after all)? Yes, in those cases, I'd catch and wrap with an explanation, usually one that blames the third-party developers whom I consider to be at fault.
dennis deems
Ranch Hand

Joined: Mar 12, 2011
Posts: 808
See, for the past year I've been working with a framework that wraps every exception it encounters. It's utterly mystifying to be told the DOM can not be rendered when the actual problem is an attempt to divide by a zero you weren't expecting. How much simpler and better it would have been for me -- how many HOURS of stress and anxiety and bafflement would have been saved -- if they had simply let through the ArithmeticException thrown by the JVM. My feelings about an NPE are exactly the same. Let me see exactly where the null reference is encountered and what it actually is. Wrapping exceptions just adds to the pile of junk I've got to dig through to find my answer.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Dennis: does the framework "wrap" an exception without including the original exception as the cause? Or does it somehow fail to follow the causal chain when logging? I frequently want to hit developers who commit those types of errors. But I don't consider wrapping to be the problem - it's either failure to wrap correctly, or crappy error logging code, that's the problem.

Alternately, even with proper wrapping, you do add more logging noise, and more slowness, than you get from just letting the exception be caught and logged once. So I usually try to (a) either log an exception, or wrap and re-throw, but not both, and (b) not re-wrap too many time unnecessarily. I sometimes have to violate (a) when I can't trust the calling code to properly log things. That results in redundant logging, which I find annoying, but better than a lack of logging.
Martin Vajsar
Sheriff

Joined: Aug 22, 2010
Posts: 3610
    
  60

Since the NPE's stemmed from the debate about catching Throwable, I was hoping for a silver bullet which would get me rid of the pesky NPEs by catching them early, but obviously no luck. I'll have to start writing better code after all.... or get much better at the gleaning.

I must admit I do sometimes code something likeand I freely admit I'm not able to glean much if the NPE happens on such a line....

Rewriting that asmakes the gleaning considerably easier. (Throwing an exception with message "Fatal: no pub in town" would be nice, but since it represents a bug anyway and the ultimate reader of such a message is me, I don't bother sometimes.)

I did catch Throwable once to log the contents of some complicated structure being processed at that time, which would otherwise be lost due to stack unwinding (the exception is rethrown, of course). This is probably what Mike was talking about, and while it certainly should not be abused, I believe it can be useful every now and then. On second thought - I should be catching Exception, not Throwable there....
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8008
    
  22

Dennis Deems wrote:...Let me see exactly where the null reference is encountered and what it actually is. Wrapping exceptions just adds to the pile of junk I've got to dig through to find my answer.

Interesting, but I don't think I've advocated trying to trap ArithmeticException exception in my rule.

Exception handling isn't an exact science, so perhaps I should explain my guiding rules, in order:
1. Prevention is better than cure.
2. A clear Exception class (possibly a custom one) beats a "generic" one.
3. A "clear" message beats an obscure one.
4. In the case of an NPE, catch it as fast as you can; especially in cases where you know the cause.
5. For any situation where I'm not either (a) swallowing an Exception, (b) throwing an IllegalArgumentException, or (c) re-throwing an NPE, declare the method to throw it (if it needs to; and in some cases when it doesn't).

If that results in the app throwing an error then so be it; they're usually the best thing to get code corrected anyway.

Winston
Seetharaman Venkatasamy
Ranch Hand

Joined: Jan 28, 2008
Posts: 5575

Winston Gutkowski wrote:
4. In the case of an NPE, catch it as fast as you can; especially in cases where you know the cause.

instead better to throw it as fast as possible. example, precondition check.
Winston Gutkowski wrote:
5. For any situation where I'm not either (b) throwing an IllegalArgumentException,

it is better to inform a user who pass wrong input to your method?
dennis deems
Ranch Hand

Joined: Mar 12, 2011
Posts: 808
Mike Simmons wrote:Dennis: does the framework "wrap" an exception without including the original exception as the cause?

Yes, and I'm sure this makes perfect sense to the developers of the framework.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Dennis: I feel your pain.
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4714
    
    7

I'm in the camp that treats most RuntimeExceptions like IllegalArgumentException and NullPointerException as programming errors and let them be detected (ideally) while writing and running unit tests or other types of tests downstream in the development process (less ideal). If they somehow find their way to production, then you missed a test.


Junilu - [How to Ask Questions] [How to Answer Questions]
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8008
    
  22

Martin Vajsar wrote:I must admit I do sometimes code something likeand I freely admit I'm not able to glean much if the NPE happens on such a line....

Yeah, and it's a pity because I'm quite fond of fluid interfaces. One of the 'prevention' things of course is to make sure that such methods can never return null; so things like returning 0-length collections and arrays rather than null.

To my mind, the real problem with not catching NPEs (and re-throwing obviously, but at least with some meaningful message) early is that they can (if you're unlucky) take an awful long time to show themselves. To me, there's nothing worse than getting an NPE in an enormous great stack trace which you can't actually trace back completely because you don't have all the source.

The reason being that NPEs are almost always the effect, not the cause.

Winston
Nitish Bangera
Ranch Hand

Joined: Jul 15, 2009
Posts: 537

I guess the StackOverFlow problem has been masked. Well Shalini, the stack actually fills with method calls and not by empty endless loops. So if you have endless method calls, they would fill up the stack and throw the stackoverflow error.


[ SCJP 6.0 - 90% ] , JSP, Servlets and Learning EJB.
Try out the programs using a TextEditor. Textpad - Java 6 api
Shalini Srivastav
Ranch Hand

Joined: Jul 21, 2012
Posts: 86
Nitish Bangera wrote:I guess the StackOverFlow problem has been masked.

Yes,i don't know what all guys did with my post.But i had got my answer through some early posts before this all.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
Shalini Srivastav wrote:
Nitish Bangera wrote:I guess the StackOverFlow problem has been masked.

Yes,i don't know what all guys did with my post.But i had got my answer through some early posts before this all.

So why ? Was there more you needed?
dennis deems
Ranch Hand

Joined: Mar 12, 2011
Posts: 808
Junilu Lacar wrote:I'm in the camp that treats most RuntimeExceptions like IllegalArgumentException and NullPointerException as programming errors and let them be detected (ideally) while writing and running unit tests or other types of tests downstream in the development process (less ideal). If they somehow find their way to production, then you missed a test.

It sounds like you have total control over your data. We're not so fortunate in my shop.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Why no stack overflow?