The best way to handle *any* exception, would be to trap generic
exceptions (the unexpected ones) on the Application level, using the
ApplicationEvents component (and trapping the OnException). That is
where you'd handle logging the error for the programmer, and display a
"less-intimidating" message to the user.
In the try..except block (which incidentially, is almost always worth
enclosing in a try..finally block, see below), you'll handle only
exceptions that you *DO* expect, and wish to handle discreetly. Those
exceptions will also be identified as specifically as possible (i.e.
with the most accurate decendant of EException).
e.g.
Application.OnException:= MyGenericHandler;
...
try
try
ConnectToDatabase(MyConnStr); // Or whatever you want to do
except
on E:EDatabaseError do // Or if you know of a
more specific exception that might occur, use it
begin
ShowMessage('Can''t connect to DB');
DoSomethingAboutTheConnection;
end;
end;
finally
DoSomeFinalizingCode; // If you need to free memory from
before the error-handling block, do it here
end;
The try..except block handles only the database error. Any other
exception gets handled on the application level. Objects that may have
been initialized before the exception gets freed in the try..finally
block, and that way an error won't cause memory-leaks.
This, to my knowledge, is the best practice regarding exception
handling.
Comments will be appreciated.
Assaf.
[Non-text portions of this message have been removed]
-----------------------------------------------------
Home page: http://groups.yahoo.com/group/delphi-en/
To unsubscribe: [EMAIL PROTECTED]
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/delphi-en/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
