|
I'm sure I've seen this used as an example in more than 1 place of how NOT to write transaction code. Maybe your guy skip read the chapter and accidentally picked up the wrong flow chart of how to write this stuff. I'm suprised that anyone who has experience with transactions would dream of doing anything other than Begin, Get the job done quick, Get the hell out.
Russell
|
|
|
|
|
I found the following C# code in an existing application I was hired to rewrite..
catch (System.OutOfMemoryException)
{
continue;
}
|
|
|
|
|
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.
|
|
|
|