StackOverFlowException
-
MS are not letting you to catch a StackOverFlowException. I wrote a evaluator/interperter using C# 1.1 . The language supports recursion about a year ago I moved to C# 2.0 and only now we found out that a too deep of a recursion throws the application without any notice. It just goes away. A simple factorial like: fact(n)(if(n == 0,1,n * fact(n-1))) vaporizes the application at fact(46) I checked MSDN and it says: Starting with the .NET Framework version 2.0, a StackOverflowException object cannot be caught by a try-catch block and the corresponding process is terminated by default http://msdn.microsoft.com/en-us/library/system.stackoverflowexception.aspx On this page they tell you to stay away from unbound recursions. What kind of recommendation is this? Guys stay away from null pointers!!
Natza Mitzi
Natza Mitzi wrote:
MS are not letting you to catch a StackOverFlowException. I wrote a evaluator/interperter using C# 1.1 . The language supports recursion about a year ago I moved to C# 2.0 and only now we found out that a too deep of a recursion throws the application without any notice. It just goes away. A simple factorial like: fact(n)(if(n == 0,1,n * fact(n-1))) vaporizes the application at fact(46)
That's how the CLR works. In fact even a tail recursive language like Scheme will fail on that. You have 2 options: 1. Increase stack space. 2. Rewrite to use iteration or tail-recursion.
xacc.ide - now with TabsToSpaces support
IronScheme - 1.0 alpha 4a out now (29 May 2008) -
MS are not letting you to catch a StackOverFlowException. I wrote a evaluator/interperter using C# 1.1 . The language supports recursion about a year ago I moved to C# 2.0 and only now we found out that a too deep of a recursion throws the application without any notice. It just goes away. A simple factorial like: fact(n)(if(n == 0,1,n * fact(n-1))) vaporizes the application at fact(46) I checked MSDN and it says: Starting with the .NET Framework version 2.0, a StackOverflowException object cannot be caught by a try-catch block and the corresponding process is terminated by default http://msdn.microsoft.com/en-us/library/system.stackoverflowexception.aspx On this page they tell you to stay away from unbound recursions. What kind of recommendation is this? Guys stay away from null pointers!!
Natza Mitzi
Natza Mitzi wrote:
Guys stay away from null pointers!!
And from people posting on the wrong forum. :-D
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Natza Mitzi wrote:
Guys stay away from null pointers!!
And from people posting on the wrong forum. :-D
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]CPallini wrote:
people posting on the wrong forum
Geeze, another one :laugh:
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
CPallini wrote:
people posting on the wrong forum
Geeze, another one :laugh:
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
Yes, another one. :-D
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Natza Mitzi wrote:
Guys stay away from null pointers!!
And from people posting on the wrong forum. :-D
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]CPallini wrote:
And from people posting on the wrong forum.
That throws WrongForumException and UraNoobException, neither of which are derived from StackOverFlowException.
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
-
Yes, another one. :-D
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]Seems like a rash of 'em lately :suss:
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
CPallini wrote:
And from people posting on the wrong forum.
That throws WrongForumException and UraNoobException, neither of which are derived from StackOverFlowException.
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
You either have problems understanding the issue or just happy to jump in with someone that can not understand the issue.
Natza Mitzi
-
MS are not letting you to catch a StackOverFlowException. I wrote a evaluator/interperter using C# 1.1 . The language supports recursion about a year ago I moved to C# 2.0 and only now we found out that a too deep of a recursion throws the application without any notice. It just goes away. A simple factorial like: fact(n)(if(n == 0,1,n * fact(n-1))) vaporizes the application at fact(46) I checked MSDN and it says: Starting with the .NET Framework version 2.0, a StackOverflowException object cannot be caught by a try-catch block and the corresponding process is terminated by default http://msdn.microsoft.com/en-us/library/system.stackoverflowexception.aspx On this page they tell you to stay away from unbound recursions. What kind of recommendation is this? Guys stay away from null pointers!!
Natza Mitzi
Natza Mitzi wrote:
Starting with the .NET Framework version 2.0, a StackOverflowException object cannot be caught by a try-catch block and the corresponding process is terminated by default
yes, that is unfortunate. On the other hand, recovering from a stack overflow in a reliable way is probably rather tricky.
Natza Mitzi wrote:
A simple factorial like: fact(n)(if(n == 0,1,n * fact(n-1))) vaporizes the application at fact(46)
That is crap. How much does one stack frame take, 100 bytes? 1KB? Now take 46 of those and your stack has run out??? IIRC the default stack size is 1 MB. I just ran a little test and 10000! runs just fine. :)
Luc Pattyn [Forum Guidelines] [My Articles]
Voting for dummies? No thanks. X|
-
MS are not letting you to catch a StackOverFlowException. I wrote a evaluator/interperter using C# 1.1 . The language supports recursion about a year ago I moved to C# 2.0 and only now we found out that a too deep of a recursion throws the application without any notice. It just goes away. A simple factorial like: fact(n)(if(n == 0,1,n * fact(n-1))) vaporizes the application at fact(46) I checked MSDN and it says: Starting with the .NET Framework version 2.0, a StackOverflowException object cannot be caught by a try-catch block and the corresponding process is terminated by default http://msdn.microsoft.com/en-us/library/system.stackoverflowexception.aspx On this page they tell you to stay away from unbound recursions. What kind of recommendation is this? Guys stay away from null pointers!!
Natza Mitzi
-
I can use a recursive factorial with numbers up to and including 170 Any higher overflows the UInt1024 that I used for it - no StackOverFlowException So what happened there? Though I agree that the advice is pointless..
I think that it depends on: a) The cost of opening a function on the stack changes b) Whether the recursion is a tail recursion or not
Natza Mitzi
-
Seems like a rash of 'em lately :suss:
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
I think his point might have been a coding horror on the part of Microsoft.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb] Jonathan C Dickinson (C# Software Engineer)
-
MS are not letting you to catch a StackOverFlowException. I wrote a evaluator/interperter using C# 1.1 . The language supports recursion about a year ago I moved to C# 2.0 and only now we found out that a too deep of a recursion throws the application without any notice. It just goes away. A simple factorial like: fact(n)(if(n == 0,1,n * fact(n-1))) vaporizes the application at fact(46) I checked MSDN and it says: Starting with the .NET Framework version 2.0, a StackOverflowException object cannot be caught by a try-catch block and the corresponding process is terminated by default http://msdn.microsoft.com/en-us/library/system.stackoverflowexception.aspx On this page they tell you to stay away from unbound recursions. What kind of recommendation is this? Guys stay away from null pointers!!
Natza Mitzi
I reduced the occurrence of the problem by splitting some methods and using a dictionary instead of large switches that cause stack bloats. Now a simple recursive factorial method works with 400 instead of 46, that is almost 900% better
Natza Mitzi
-
I can use a recursive factorial with numbers up to and including 170 Any higher overflows the UInt1024 that I used for it - no StackOverFlowException So what happened there? Though I agree that the advice is pointless..
My answer below: I reduced the occurrence of the problem by splitting some methods and using a dictionary instead of large switches that cause stack bloats. Now a simple recursive factorial method works with 400 instead of 46, that is almost 900% better
Natza Mitzi
