Handle an exception?

I use Delphi 4 Professional and around certain blocks of code that i know can cause an exception (mainly user input) i use TRY..EXCEPT blocks.

However, i downloaded the latest version of MemProof and ran my program through it while i tested it out.  It shows the exceptions happening in the "Resource Counters" section as i put invalid information in to test out the program.  The problem is that when i then close the program MemProof shows that the exceptions are still using resources (it works out 3 bytes per exception i think).

Example of a TRY...EXCEPT block

Try
    Result:= False
   
   {Code that if all goes well will set Result to True}

Except
   // Set result to False to show failure
   Result := False;

End

Anyone know why this is and how to reclaim the lost resources?
mi6agentAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
esoftbgConnect With a Mentor Commented:
Hi mi6agent, I don't believe anymore Memproof !

I made 2 tests for 2 different .exe made by Delphi 7:

1). Application which contains 20 Forms and compiles 68737 lines Delphi code. Running under Memproof, after it's closure Memproof displays nothing at the Resources Details page (no matter there is or not an exception) ????

2). Application which contains 1 Form and compiles 74 lines Delphi code. Running under Memproof, after it's closure:
     2.1). Memproof displays at the Resources Details page when there is not exception:
             303  Virtual Memory        02190000       4096  VirtualAlloc(00000000,4096,4096,64)
     2.2). Memproof displays at the Resources Details page when there is an exception:
             303  Virtual Memory        02190000       4096  VirtualAlloc(00000000,4096,4096,64)
absolutely identical results ????

0
 
Ivanov_GConnect With a Mentor Commented:
I don't know about MemProof, but I will make some remarks on your code:

Result := False; // thus you avoid compiler warning "The Values might not be initialized" or smth like that...
try
   {Code that if all goes well will set Result to True}

except
   // the value of Result is already set before TRY block
   on E: Exception do
      begin  
        MessageDlg(E.Message, mtError, [mbOK], 0); // show the exception message
        Exit;  // exit from the routine
      end;
end;
0
 
mi6agentAuthor Commented:
oops, my mistake - i always use Result:= False  before the Try

I tried

except
    on E: Exception do
      begin  
        MessageDlg(E.Message, mtError, [mbOK], 0); // show the exception message
       Exit;  // exit from the routine
     end;

but seems Memproof claims resources still being used - even though no major resources are used in any of the code, it is always just the exception that seems to not release some bytes (according to Memproof of course).

I'm just interested in why an exception - that i thought is handled - uses resources.  ie: does an exception use resources that must be freed?



0
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

 
esoftbgCommented:
function  DangerousFunc(May be some parameters): Boolean;
begin
  Result:= True;
  try
     {Dangerous code that is possible to cause an exception}
  except
     Result := False;
     MessageDlg(E.Message, mtError, [mbOK], 0);
    // There is nothing to free. That is a usual way for handle a possible exception
  end;
end;
0
 
mi6agentAuthor Commented:
Thing is, i don't use MessageDlg(E.Message, mtError, [mbOK], 0); as it is a function which will return true or false.

Could that cause the problem (not displaying the message)?
0
 
esoftbgCommented:
It could not be the problem. It is your decision to display or not a message. There is absolutely correct to be as following:

function  DangerousFunc(May be some parameters): Boolean;
begin
  Result:= True;
  try
     {Dangerous code that is possible to cause an exception}
  except
     Result := False;
     // There is nothing to free. That is a usual way for handle a possible exception
  end;
end;

If there occurs an exception the function will return False, otherwise it will return True.
0
 
Ivanov_GCommented:
{Code that if all goes well will set Result to True}  ???

Do you create some object here? Can you paste some code?
0
 
mi6agentAuthor Commented:
It happens in any try..except block.  Even those that do not create an object - ie: i have a try..except block around testing for a numeric value and it too will cause the problem.


{I know i can use other ways to test for numeric values - this is just an example to show the problem of  the try..except block}

ie:

result:=false
try
  tmp := strtoint(edit1.text);
  if tmp >100 then result := true;
except
  result:=false
end;
0
 
esoftbgCommented:
it is possible to avoid exception at all:

function  IsNumeric(V: Variant): Boolean;
var
  I:      Integer;
  Code:   Integer;
begin
  Result := False;
  try
    Val(V, I, Code);
    Result := (Code=0);
  except
    Result := False;
  end;
end;
0
 
esoftbgCommented:
function  IsNumeric(V: Variant): Boolean;
var
  I:      Integer;
  Code:   Integer;
begin
  Val(V, I, Code);
  Result := (Code=0);
end;
0
 
mi6agentAuthor Commented:
thanks esoftbg but as i said, the example code was just to show the type of exception - ie: no objects created within the try..except - which is why i am wondering why memproof is showing resources of 3 bytes per exception.

btw - memproof is available free from http://www.automatedqa.com/downloads/memproof.asp if you would like to see for yourself the problem about try..except blocks.
0
 
esoftbgCommented:
I just downloaded memproof for Delphi 7, but I don't know how to use it, it is without help files ....
0
 
mi6agentAuthor Commented:
Just unzip it, then double click the memproof exe - use file\open to load in the program you want to monitor.

Select Run and Memproof will run your program and show you all of the resources it uses.  When you close your program Memproof will show you all of the resources that your program left "open" - (ie: things that should be fixed)

0
 
esoftbgCommented:
O.k. I understand now that MemProof will start the .exe created by Delphi. (I did expect that will monitor an application started under Delphi IDE). I will test an exe with exception just now ....
0
 
esoftbgCommented:
And after closing the app, how can I know is all resources freed ?
0
 
mi6agentAuthor Commented:
Click on the "Resource Counters" icon on the left panel - it will list all the resources used and freed by the program
0
 
mi6agentAuthor Commented:
"Resource Details" icon will give you more information about each of the "problem" areas such as non-freed objects, etc
0
 
esoftbgCommented:
Next is the result after closing .exe (created by Delphi 7) without exception // StrToInt('128');
      303  Virtual Memory        02190000       4096  VirtualAlloc(00000000,4096,4096,64)
Next is the result after closing .exe (created by Delphi 7) after  exception    // StrToInt('128z')
      303  Virtual Memory        02190000       4096  VirtualAlloc(00000000,4096,4096,64)
I think Delphi 7 created better .exe than Delphi 4 ....
0
 
mi6agentAuthor Commented:
>I think Delphi 7 created better .exe than Delphi 4

Not if those numbers are the in the "current size" column when you close the exe.

The first 4096 - if that is in the current size column, then your exe is leaking 4k - i had the same problem till i fixed the form.pas file as there was a known leak in delphi.  The other 4096 and 64 are also leaks if those numbers are in the current column.

Memproof is a good program to have don't you think?

What mine showed was in the "area" column under "exception" and 3 bytes per time i self caused the error.  Oddly enough i think i found the issue - the exception happens if i check for <0 and i entered -0 to convert.
0
 
esoftbgCommented:
> Memproof is a good program to have don't you think?
O.k. it is a good programm, but it is possible there is no memory leak ....
May be Windows memory manager will deallocate that memory later ....
You may force the memory manager by

procedure TFormMain.FormDestroy(Sender: TObject);
begin
  SetProcessWorkingSetSize(GetCurrentProcess, $FFFFFFFF, $FFFFFFFF);
end;

(it works perfect under Windows XP and Delphi 7):

Cheers !
0
 
mi6agentAuthor Commented:
>May be Windows memory manager will deallocate that memory later

Yes, but "later" is not always a good idea which is why i use memproof to ensure the program has no leaks while it is running.
0
 
esoftbgCommented:
Just force the memory manager on main form's OnDestriy event and all will be o.k. (My example is o.k.)
0
 
esoftbgCommented:
(My example is o.k.): i.e. at the Resources Details page displays nothing after .exe is closed under Memproof, no matter with or without exception.
0
 
mi6agentAuthor Commented:
Ok, i think i need to recheck my coding because Memproof is showing some exception issues which i cause when testing the program but are not cleared.  So i think it is something i have forgotten or left out.

Anyway, what i shall do is raise the points and then split the points between esoftbg and Ivanov_G for helping - with a grade A of course :)
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.