Board index » delphi » Re: D2005 Code Folding

2005-08-11 06:48:15 AM
delphi101
Dave Nottage [TeamB] writes:
You two on TeamB are wrong. ;-)
All he needs to do to make the code more robust is set a boolean value after calling ECS.
This way he can check the value before freeing the critical section.
 

Brian Moelk writes:
I would personally check to make sure if it entered the critical section before freeing it.
That's all he needed to do IMAO.
 

putting the ECS outside the try, save the extra EnteredCriticalSection
variable declaration.
 

Jason Southwell writes:
if you still want to execute code in or after the try block.
( If an exception was to occur execution would have exit the routine. )
Moreover, I believe it is a good practice of putting routines you think
are going to fail in a try finally or a try except block.
So, in this case, I think Allen was 100% correct in what he wrote.
But I do believe he needs some more code in the try finally block
to make sure he entered the critical section before freeing it.
 

 

Allen Drennan napsal(a):
matching LCS call for each ECS call. By putting a ECS call *inside*
the try..finally block you actually protecting this ECS call itself
and take a care of situations where this ECS call could raise an
exception. But why? Instead, you have to protect the only code that
executes *after* the critical section was acquired (i.e. after a
successful call to ECS) in order to make sure this code does not throw
any exceptions so that a call to LCS in finally clause can be
guaranteed to occur in any case. Do you see the difference?
called everytime the preceding ECS call succeeds.
--
Ivo Bauer
Software Developer
OZM Research, s.r.o.
________________________________________________
ModLink - MODBUS Messaging Components for Delphi
www.ozm.cz/ivobauer/modlink/
________________________________________________
 

Michael Anonymous napsal(a):
isn't it?
--
Ivo Bauer
Software Developer
OZM Research, s.r.o.
________________________________________________
ModLink - MODBUS Messaging Components for Delphi
www.ozm.cz/ivobauer/modlink/
________________________________________________
 

Michael Anonymous napsal(a):
in try..finally block. But in this case you're *not* interested in
trapping exception that the ECS call may throw. What you need here to
accomplish is to protect the code executing *after* the critical
section was entered/acquired in order to ensure that corresponding LCS
call is not bypassed.
--
Ivo Bauer
Software Developer
OZM Research, s.r.o.
________________________________________________
ModLink - MODBUS Messaging Components for Delphi
www.ozm.cz/ivobauer/modlink/
________________________________________________
 

Michael Anonymous napsal(a):
--
Ivo Bauer
Software Developer
OZM Research, s.r.o.
________________________________________________
ModLink - MODBUS Messaging Components for Delphi
www.ozm.cz/ivobauer/modlink/
________________________________________________
 

Brian Moelk writes:
to minimize possible negative consequences"
Source: en.wikipedia.org/wiki/Future_proof
Putting the call to ECS outside the try block creates a situation where
if the ECS raises an exception,
one's code in or after the try block might never be executed.
 

Brian Moelk writes:
Adding little difference can make one's code even more robust.
 

Michael,
re-invent the "try ... finally" semantics that you are deliberately
subverting by putting code in the wrong place:
var
Success : Boolean;
sl : TStringList;
begin
Success := False;
try
sl := TStringList.Create; // Danger of out of memory exception.
Success := True;
DoStuff;
finally
if Success then
sl.Free;
end;
end;
...is that code robust? Yes, for the most part. Is it 'good code'? No, it is
a pointless workaround for the fact that:
var
sl : TStringList;
begin
try
sl := TStringList.Create; // Danger of out of memory exception.
DoStuff;
finally
sl.Free;
end;
end;
...is simply ASKING for an access violation. Is the problem the lack of a
boolean variable? No. The problem is that the programmer should have
written:
var
sl : TStringList;
begin
sl := TStringList.Create; // Danger of out of memory exception.
try
DoStuff;
finally
sl.Free;
end;
end;
...in the first place.
Eryk
PS: This reminds me of threads back in D1 days when 'exceptions' were a 'new
idea' to many. "Twilight Zone" !!
 

Ivo Bauer writes:
If ECS raises an exception,
the code in or after the try block may never be executed.
 

Michael Anonymous napsal(a):
clause nor the code inside the finally should be executed. If you put
ECS call inside try..finally block and this ECS call raises an
exception, the LCS inside the finally clause will get called, which is
wrong (it should be called *if* and *only*if* the preceding ECS call
succeeded).
--
Ivo Bauer
Software Developer
OZM Research, s.r.o.
________________________________________________
ModLink - MODBUS Messaging Components for Delphi
www.ozm.cz/ivobauer/modlink/
________________________________________________
 

Eryk writes:
In the case of the ESC subroutine,
it's worth take a few extra measure to insure that your program continues to run smoothly and
not enter into some sort of deadlock.