|
Ahhh, yes a true classic.
--
Real programmers don't comment their code. It was hard to write, it should be hard to understand.
|
|
|
|
|
Exquisite gems in programming right?
|
|
|
|
|
How about a new operator in the catch block?
|
|
|
|
|
I once saw a program that allocated a huge array on startup. When a certain out of memory condition occurred, it freed the array, then performed a shutdown (hoping that the newly available memory would suffice).
I was quite frightened.
Failure is not an option - it's built right in.
|
|
|
|
|
I can just imagine that guy sitting there thinking, "Out of memory... PROBLEM SOLVED!!!111!11one"
|
|
|
|
|
|
catch(OutOfMemoryException ex) {
Ram r = new Ram(RamDualChannelMode.Enabled, 512, 512);
r.Install(RamInstallMode.HotPlug);
}
If you truly believe you need to pick a mobile phone that "says something" about your personality, don't bother. You don't have a personality. A mental illness, maybe - but not a personality. - Charlie Brooker
My Blog - My Photos - ScrewTurn Wiki
|
|
|
|
|
I think the "new Ram()" call will fail, hence installation would be impossible...
How unfortunate!
|
|
|
|
|
Wow, run out of memory and just keep going as if nothing happened
"Any sort of work in VB6 is bound to provide several WTF moments." - Christian Graus
|
|
|
|
|
Regards,
Satips.
Don't walk in front of me, I may not follow;
Don't walk behind me, I may not lead;
Walk beside me, and just be my friend. - Albert Camus
|
|
|
|
|
Found in C++ code of one of my colleagues several years ago:
if (x == 0)
{
y = 0;
}
else
{
y = x;
}
Asad
|
|
|
|
|
I would wonder whether or not it was originally something like:
if (x == FALSE)
{
y = 0;
}
else
{
y = x;
}
(With FALSE being 0 of course.)
|
|
|
|
|
Something similar:
if (x == false)
{
return false;
}
else
{
return true;
}
Jeff Clark
Systems Architect
JP Clark, INC.
Columbus, Ohio
|
|
|
|
|
Your example is from someone not knowing (or being reluctant to use) boolean logic:
return (x != false); would have been the same.
Failure is not an option - it's built right in.
|
|
|
|
|
Or just:
return x;
Jeff Clark
Systems Architect
JP Clark, INC.
Columbus, Ohio
|
|
|
|
|
Sure.
That would convert X's type (maybe BOOL?) implicitly to bool, whereas the operator!= I used does this explicitly.
It probably doesn't matter.
Failure is not an option - it's built right in.
|
|
|
|
|
PIEBALDconsult wrote: (With FALSE being 0 of course.)
No longer. C# is getting stricter. You have to explicitly do a type cast to escape the compiler wrath and whip.
|
|
|
|
|
Does it make more sense if x is of type signed int and y of type unsigned int ?
|
|
|
|
|
No...
---
single minded; short sighted; long gone;
|
|
|
|
|
|
Wasn't thinking, and had to wait for a window to dispose properly before redisplaying it (long story)
I was about to code this when my first cup of coffee hit me:
public void redisplay ()
{
try
{
}
catch (Exception e)
{
Thread.Sleep (100);
redisplay();
}
}
|
|
|
|
|
Great coding
Regards,
Sylvester G
|
|
|
|
|
To be honest, I find the general catch more disturbing than the recursion.
|
|
|
|
|
Slightly less bad than having an empty catch, imo
|
|
|
|
|
Regards,
Satips.
Don't walk in front of me, I may not follow;
Don't walk behind me, I may not lead;
Walk beside me, and just be my friend. - Albert Camus
|
|
|
|