In general, you do not know when will your application raise an exception. What's more, you should not guard each any every "suspicious" code section in a try-except-finally block.
The *best* technique to avoid errors is to use if-then blocks. However, when an exception occurs (those NOT handled by your code) you shoud let Delphi handle the exception. You might, however, use the OnException event of the global Application object to change the default behavior that occurs. One way to go is to use the TApplication object (located on the "Additional" tab of the component palette) to be able to handle all exception in one place.
Now, beside handling exceptions in the OnException event, you could also LOG all exceptions to a simple text file.
Drop a TApplication component on the main form of your application and handle the OnException event. The code below, provides one such logging technique. Each exception is added to a simple ASCII file with the date and time of the exception (along with the exception's message):
~~~~~~~~~~~~~~~~~~~~~~~~~
procedure TForm1.ApplicationEvents1Exception(
Sender: TObject;
E: Exception) ;
var
ErrorLogFileName : string;
ErrorFile : TextFile;
ErrorData : string;
begin
ErrorLogFileName := ChangeFileExt(Application.ExeName,'.error.log') ;
AssignFile(ErrorFile, ErrorLogFileName) ;
//either create an error log file, or append to an existing one
if FileExists(ErrorLogFileName) then
Append(ErrorFile)
else
Rewrite(ErrorFile) ;
try
//add the current date/time and the exception message to the log
ErrorData := Format('%s : %s',[DateTimeToStr(Now),E.Message]) ;
WriteLn(ErrorFile,ErrorData) ;
finally
CloseFile(ErrorFile)
end;
//Show the exception
Application.ShowException(E) ;
end;
~~~~~~~~~~~~~~~~~~~~~~~~~
Note: while designing your application, when launching from the IDE, you might get tired of the Delphi's Integrated Debugger. Here's how to stop/disable the Intergrated Debugger from loading and stoping your program execution.
Comment from a reader:
Mike Montagne: A problem with the concept of 'Logging Exceptions in Delphi Applications' is that exceptions often break down the ability to perform the I/O operations of logging -- which of course defeats the purpose of logging, as a usual desire for instance is to know the value of a field which might engender an exception. My experience with logging (in Delphi) underscored the further idea that there is little you can learn which isn't already apparent from your source-level debugging. For instance, if you are writing components and have descended numerous instances of a given class, you may not be able to tell which of the instances is causing an exception unless you add a pseudoname field -- which also means that then you can detect the offending instance at source-level debugging.
As a consequence, the few times I've thought I needed to use such a thing, all it did for me is confirm in hard copy what values pre-existed an exception incident (which of course is a similar purpose to logging exceptions).
Delphi tips navigator:
» Placing a Form inside a TabSheet of a TPageControl
« How to handle the TMaskEdit's internal "Invalid input value. Use escape key to abandon changes" error in Delphi
