|
raddevus wrote: Did you steal that analogy from someone else?
No. What do you think? I just have some experience with hitting trees with cars.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
experience, experience and again experience.
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
I had no problem at all to set breakpoints and debug the code - no crash of VS...
Actually the code has that logical problem of infinite recursion, but VS just stops after the application comes to a 0x800703e9 (COR_E_STACKOVERFLOW) error... which in my cases happening after 11708 iterations...
Quote: The program '[19424] ConsoleApp2.exe' has exited with code -2147023895 (0x800703e9).
StackOverflowException Class (System)[^]
When can you catch a StackOverflowException? – jaredpar's WebLog[^]
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
modified 1-May-18 2:44am.
|
|
|
|
|
Breakpoint is not a problem..
But why would you put a breakpoint there if you didn't know the bug was there in the first place?
That was my problem! Only 600 files changed... Had to the find the wrong change.... Didn't have the insight to put the breakpoint in the right spot right away!
Now, now, I wonder, how come it was so hard for you to understand that?
I think I might not have make myself very clear.. not sure though how to improve my communication though... Any tips?
modified 1-May-18 7:27am.
|
|
|
|
|
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!
|
|
|
|