|
It is true. Even knowing that there was a overflow exception does not help, as VS does not tell where and it is uncatchable...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
|
|
|
|
|
Super Lloyd wrote:
That was my problem! Only 600 files changed...
All of them using recursion? 
Super Lloyd wrote: Didn't have the insight to put the breakpoint in the right spot right away!
If you can reproduce the error, or have a log that shows which method is executed, you'd at least have had a starting point. Then you step through the code.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: All of them using recursion?
quick questwion, how many method in your code use recusion right now? are you sure?
Yeah, just as I thought! 
|
|
|
|
|
Two in the current codebase. Yes, very sure, as I wrote it.
Are you saying you are unsure of what code you are writing? 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Your codebase must be a one man small project then.. or you have prodigious memory... (or young maybe?)
Further this method was not even mean to be recursive.. it's just I got 2 method with the same name but different parameter, just accidentally forgot the extra parameter..
BTW I believe there are 0 recursion in my app but who knows... there was this accidental one for instance...
modified 1-May-18 23:14pm.
|
|
|
|
|
Super Lloyd wrote: Your codebase must be a one man small project then.. or you have prodigious memory... (or young maybe?)
None of those three.
Super Lloyd wrote:
Further this method was not even mean to be recursive.. it's just I got 2 method with the same name but different parameter, just accidentally forgot the extra parameter..
That's why we have logging
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
well.. it was a bug in the logging class, if you must know...
|
|
|
|
|
Eddy Vluggen wrote: Super Lloyd wrote: Your codebase must be a one man small project then.. or you have prodigious memory... (or young maybe?)
None of those three.
Ha!
I was already old when the earth was young!
|
|
|
|
|
No, but experienced enough to add a hint in XML comment when recursion is used. Logging is easily tested with unit-tests.
Anything else?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Yeah, you should work on your communication skills.
Also, most of this codebase is written for being hard to test. One of the thing I am changing.
Though I was not planning to using test every single method or allegedly trivial ones... nor every single parameter... (more than a bazillion possible combination there)
Beside my fake test application with all the real code except fake - virtual faster hardware was also crashing mysteriously. Bummer.
modified 2-May-18 9:59am.
|
|
|
|
|
Super Lloyd wrote: Yeah, you should work on your communication skills.
I don't work in marketing.
Super Lloyd wrote: Also, most of this codebase is written for being hard to test. One of the thing I am changing.
I'd expect a logger to be some independent item, or even framework.
Super Lloyd wrote: Though I was not planning to using test every single method or allegedly trivial ones... nor every single parameter... (more than a bazillion possible combination there)
Depending on how large the code-base is, testing everything is rather unrealistic. And yes, brownfields are the prime source for material for the Weird & Wonderfull forum here
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
This document is outdated.
If you cause a stack overflow yourself (outside a catch block) (not throwing the exception mind you, but real unbounded recursion) VS will stop and show you the stack.
Many a times it helped me in the recent past! 
Otherwise yeah, one could never catch and terminate such an exception. I knew that too. Doesn't help though!
|
|
|
|
|
Actually, when you think about it, actually managing to catch an exception in an exception handler that is itself creating a stack overflow, well, that would be impressive.
|
|
|
|
|
Perhaps, indeed.
But that would still be handy!
|
|
|
|
|
I'm using VS2017 and it works as expected
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
I'm using VS2017 and it works as expected That means it crashed
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Are you catching exceptions when they are thrown or only after they are dealt with?
If it is the latter, I think that even if you want to catch StackOverflowException's, it will not work because there's no more stack to let you do anything and it is probably using something like Environment.FailFast().
Environment.FailFast Method (String) (System)
|
|
|
|
|
Paulo Zemek wrote: Are you catching exceptions when they are thrown or only after they are dealt with?
What does that means? I mean what does "catching exception after they are dealt with" means?
|
|
|
|
|
You can debug exceptions when they are thrown. This means you stop even if there's a catch block that's going to "eat" the exception.
Or, you can debug only exceptions that are uncaught or are rethrown. In this case, if there's a catch clause, you will not see the exception until it is rethrown (if it ever is rethrown).
Usually on the second case, an exception that kills the application will not give you a chance to debug it. On the first case, you usually have that option (and for an exception throwing another exception, throwing another exception you would be bothered thousand of times before the app is killed).
|
|
|
|
|
I am doing a lot of computational maths work at home at the moment and, just for giggle, I thought of writing the following method. Code behave as incorrectly as expected! 
static void Main(string[] args)
{
var e = 1e18;
Console.WriteLine(IsEven(e));
Console.WriteLine(IsEven(e + 1));
Console.WriteLine(IsEven(-e));
Console.WriteLine(IsEven(-e + 1));
}
bool IsEven(double d)
{
if (d < 0) return (d % 2) > -1;
return (d % 2) < 1;
}
|
|
|
|
|
What makes this even nicer is that both 1.0e+18 and 1.0 are exactly representable as a double, but their sum isn't. A nice demonstration of one of the pitfalls of floating-point arithmetic.
Ad astra - both ways!
|
|
|
|
|
ha, yeah, it's better than summing up 0.1 10 times, since 0.1 is an approximation to start with...
|
|
|
|
|
When you start with approximations...
You should conclude with "apporximately correct" = "correct"
There are ONLY Zeroes and Ones... Everything else is up for interpretation!
|
|
|
|
|
01001100 01101001 01101011 01100101 00101100 00100000 01110100 01101111 01110100 01100001 01101100 01101100 01111001 00100000 01101101 01100001 01101110 00100001
|
|
|
|
|
No finer compliment to a response has EVER been paid...
Thank You!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
