Had a quick look - single stepped through the assembler code. The base issue
is that a virtual method is being called on a uninitialised object, so it
can attempt to execute code anywhere. Don't have time to take it any further
at the moment.

Under the Delphi debugger in my case, it actually showed a blank/nil message
and then fell over - it actually called TComponent.UpdateRegistry to get the
message string - which executed okay - even more crazy (Did not check the
stack entries though - which I suspect is the issue in this case as it
called a class procedure)!

About the only way to avoid this that I can think of is to add copious
Assert statements. And you have to in this case cast the object back to
TOBject, else the assert will not work.
eg Assert( Assigned( AList ) and (TObject(Alist) is TStringList),
'Whoops!');

Myles.

-----Original Message-----
From: Myles Penlington [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 19 August 2003 09:17
To: Multiple recipients of list delphi
Subject: RE: [DUG]: Handling Exceptions


Hmm,
If you debug, I would like to know the values causing the issue.
What you are saying - should not happen. However we had a similar case
recently with incorrect/incomplete ADO installs. 

When a ADO connection was first opened, the application crashed without any
exception begin thrown/dr watson etc . Ie nothing - just disappeared from
the task manager - fastest program close I have ever seen.

Myles.


-----Original Message-----
From: Vaughan, Benjamin Carl [mailto:[EMAIL PROTECTED]
Sent: Monday, 18 August 2003 15:02
To: Multiple recipients of list delphi
Subject: [DUG]: Handling Exceptions


Hi All,

I have currently been working on an Exception handler for one of my
applications and was giving it some test cases.

I have found some exceptions that can not be handled.. 
e.g

var
  aList : TStringList;
begin
  Showmessage(aList.Text);
end;

This sort of exception basically exits you out of the application
immediately with out firing an Application.OnException event.

I am guessing this happens because the error occurs somewhere down in
the windows API call displaying the message in this case. Does anyone
know how to handle these sorts of exceptions without the application
exiting? (other than the way of checking in advance)

Cheers
Ben 
---------------------------------------------------------------------------
    New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
                  Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED] 
with body of "unsubscribe delphi"
Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
---------------------------------------------------------------------------
    New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
                  Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED] 
with body of "unsubscribe delphi"
Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/
---------------------------------------------------------------------------
    New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
                  Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED] 
with body of "unsubscribe delphi"
Web Archive at: http://www.mail-archive.com/delphi%40delphi.org.nz/

Reply via email to