• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Why no stack overflow?

 
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Why it doesn't throw StackOverflowError while below will ?
 
Ranch Hand
Posts: 36
Chrome Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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....
 
Shalini Srivastav
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 4568
9
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ?
 
Marshal
Posts: 79179
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 4568
9
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
lowercase baba
Posts: 13089
67
Chrome Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Sheriff
Posts: 3837
66
Netbeans IDE Oracle Firefox Browser
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Bartender
Posts: 1051
5
Hibernate Eclipse IDE Chrome
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Master Rancher
Posts: 4806
72
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 Vashko
Sheriff
Posts: 3837
66
Netbeans IDE Oracle Firefox Browser
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Marshal
Posts: 79179
377
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I started off some interesting discussion there
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:I started off some interesting discussion there


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

Winston
 
Mike Simmons
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 808
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 Vashko
Sheriff
Posts: 3837
66
Netbeans IDE Oracle Firefox Browser
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Ranch Hand
Posts: 5575
Eclipse IDE Windows XP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 808
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dennis: I feel your pain.
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Ranch Hand
Posts: 537
Eclipse IDE Python Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Shalini Srivastav
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Master Rancher
Posts: 4806
72
  • Likes 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 808
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
The moustache of a titan! The ad of a flea:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic