|
My favorite columnist, the late Paul DiLascia used to write in the header of his code, "If this code works it was written by Paul DiLascia. If not, I don't know who wrote it."
modified 11-May-18 17:28pm.
|
|
|
|
|
Rick York wrote: "If this code works it was written by Paul DiLascia. If not, I don't know who wrote it."
An a shorter version: "If this code works, it wasn't written by you!"
|
|
|
|
|
A while back, I related the experience of losing FKs in a database, without having an inkling of what may have caused it.
Various people came up with (reasonable) suggestions, like removing a constraint to facilitate adding records, or bulk inserts etc.
However, I can now reveal the culprit. A product from a third party developer (who originally developed the system) that proceeded to go through the DB removing FKs without any attempt to reinstate them.
The process was run a few months ago, luckily it looks like we only have a few cases of erroneous data resulting. This is a small miracle in itself.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Rob Grainger wrote: However, I can now reveal the culprit. A product from a third party developer (who originally developed the system) that proceeded to go through the DB removing FKs without any attempt to reinstate them. "Sir, we're getting primary key exceptions!"
"Ah, just remove the constraints from their database, that'll fix it."
Makes me wonder about liability
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.
|
|
|
|
|
"RDBMSs are inefficient - we can hand-roll our own referential integrity in code, using a couple of junior devs, in less than a week"
- Every development shop ever.
|
|
|
|
|
Essential for a fully abstracted repository layer, but if you're already married to a persistence technology...
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
And they would have gotten away with it too, if it weren't for you meddling kids!
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
The application must not rely on such things for proper functioning!
|
|
|
|
|
I had the following code in my app. Turns out you just CAN'T debug that code. At least with Visual Studio 2017,
It will crash your process instantly and you will be left without any clue as to what was wrong!!
Gotta report that to Microsoft..
Meanwhile, behold the evilest safe C# code that can be!
class Program
{
static void Main(string[] args)
{
try { Fail(); }
catch (Exception ex) { Log(ex); }
}
static void Fail()
{
throw new NotSupportedException("You Fool!");
}
static void Log(Exception ex)
{
var sb = new StringBuilder();
Log(ex);
Console.WriteLine($"Problem: {sb}");
}
}
[EDIT] To clarify, of course this code is buggy, it's a bug repro.
But most remarkably the program just crash without hint from Visual Studio. Even if you ask Visual Studio to stop on StackOverflowException, it won't!
[EDIT2] Setting breakpoints is not the problem...
But why would you put a breakpoint there if you didn't know the bug was there in the first place?
FYI it's about 1 month of work before this bug came to light!
modified 1-May-18 7:39am.
|
|
|
|
|
Recursion without exit condition is killing it ?
Zen and the art of software maintenance : rm -rf *
Maths is like love : a simple idea but it can get complicated.
|
|
|
|
|
Of course this code is buggy, that's the point.
But most notably the program just crash without hint from Visual Studio. Even if you ask Visual Studio to stop on StackOverflowException, it won't!
|
|
|
|
|
It's exceptions all the way down.
This space for rent
|
|
|
|
|
Boom!
|
|
|
|
|
To iterate is human, to recurse divine. But not in this case.
Of course it does not stop anymore. The process is too busy spiraling down to its death and after that it does not break to report anything. The debugging session is over and the vultures are eating what's left of your process.
Would you expect one of the self driving cars to bring you to the hospital after hitting a tree?
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.
|
|
|
|
|
CodeWraith wrote: Would you expect one of the self driving cars to bring you to the hospital after hitting a tree?
That would be a handy feature!
|
|
|
|
|
Would be a handy feature, if it stops hittings trees on the way to the hospital.
|
|
|
|
|
|
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.
|
|
|
|