Capture exception in Delphi Application.OnException before try except block - delphi

I want to log every exception raised in the delphi application.
For that, I overrided the Application.OnException event with one of my own in the project source code.
program Project;
uses
Vcl.Forms,
Unit1 in 'Unit1.pas' {Form1},
Logger in 'Logger.pas',
JCLDebugHandler in 'JCLDebugHandler.pas';
{$R *.res}
begin
Application.Initialize;
Application.OnException := TApplicationException.AppException;
Application.MainFormOnTaskbar := True;
Application.CreateForm(TForm1, Form1);
Application.Run;
end.
This works perfectly, but I´m failing at catching with this solution the exceptions catched in a try-except block.
When the exception is catched in the except block, it just not triggers the Application.OnException event.
Is there any way to first catch it in the Application.OnException event rather than the except block?

The Application.OnException handler is only called for unhandled exceptions.
An unhandled exception is one where no try..except block has caught the exception or where it has been caught and then re-raised.
Using some trivial examples to demonstrate, let's assume that this is virtually the only code in the application and that there are no other exception handlers...
try
a := 42 / 0;
except
on EDivisionByZero do
begin
Log.i('Silly division by zero error has been logged');
raise;
end;
end;
In this case, the exception is caught but the application has no strategy for handling the exception so simply logs that it has occurred and then re-raises the exception. Execution will continue in any outer except block. If there are none, or if any that may exist also re-raise the exception, then eventually the exception will reach the Application.OnException handler.
But an exception handler might not need to re-raise an exception:
try
a := 42 / 0;
except
on EDivisionByZero do
a := 0;
end;
In this case, the exception handler handles the division by zero and does not re-raise it since the code is happy to proceed with a result of zero in that case (unlikely, but this is just an example).
Since the exception is not re-raised, execution proceeds (after the try..except block) as if the exception had never happened in the first place. Your Application.OnException will never know about it.
In summary: Application.OnException is your last chance to deal with an unhandled exception. It is not the first opportunity to respond to any exception.
Intercepting exceptions at the moment that they occur, before any application code has had an opportunity to react or deal with them is possible, but is pretty advanced stuff and no simple mechanism is provided "out of the box".
Fortunately there are 3rd party libraries you can use that may provide the capabilities you are seeking to introduce into your application.
A popular one for Delphi which you might wish to check out is madExcept.

I finally used JCL for capturing and logging all my exceptions. I created a new .pas file with the following code:
/// <summary>
/// Inicializa JCL para capturar la informacion necesaria de la excepcion.
/// </summary>
initialization
JclAddExceptNotifier(SetExceptionError);
JclStackTrackingOptions := JclStackTrackingOptions + [stExceptFrame];
JclStartExceptionTracking;
/// <summary>
/// Finaliza la notificacion de JCL luego de capturar la informacion necesaria de la excepcion.
/// </summary>
finalization
JclRemoveExceptNotifier(SetExceptionError);
end.
With this code, I can capture the exception and treat it in my function SetExceptionError. I was avoiding using some 3rd party framework for this simple logging.

Related

Exception on FormCreate is not thrown

By default any unhandled exception occurring in TForm.OnCreate will lead to an error message beeing shown instead of an exception beeing thrown.
The reason is this code in VCL.Forms:
function TCustomForm.HandleCreateException: Boolean;
begin
Application.HandleException(Self);
Result := True;
end;
All my forms inherit from TMyForm. I plan to override this function to solve the problem:
function TMyForm.HandleCreateException: Boolean;
begin
Result := False;
end;
But I cannot imagine anybody wanting an exception on form creation to be swallowed, leaving a potentially halfly initialized form, yet this code still exists in VCL. This leaves me with the question:
Are there any reasons to not treat unhandled exceptions on form creation this way? Or are there better options to handle my problem?
Edited to clarify the original problem. I have the following code:
try
//...
Frm := TBooForm.Create(...);
Frm.ShowModal;
//...
except
//exception in TBooForm.FormCreate not landing here.
end;
If I don't touch global exception handling, an unhandled exception in TBooForm.FormCreate() will not land in the exception block. Instead Frm will display in halfly initialized state, leading to hard to track errors.

Exceptionhandling with IOmniParallelTask not working

Unhandled exceptions within IOmniParallelTask execution should (as I understand the docs) be caught by the OTL and be attached to IOmniTaskControl instance, which may be accessed by the termination handler from IOmniTaskConfig.
So after setting up the IOmniParallelTask instance with a termination handler like this:
fTask := Parallel.ParallelTask.NoWait.NumTasks(1);
fTask.OnStop(HandleOnTaskStop);
fTask.TaskConfig(Parallel.TaskConfig.OnTerminated(HandleOnTaskThreadTerminated));
fTask.Execute(TaskToExecute);
any unhandled exceptions within TaskToExecute:
procedure TFormMain.TaskToExecute;
begin
Winapi.Windows.Sleep(2000);
raise Exception.Create('async operation exeption');
end;
should be attached to the IOmniTaskControl instance you get within the termination handler:
procedure TFormMain.HandleOnTaskThreadTerminated(const task: IOmniTaskControl);
begin
if not Assigned(task.FatalException) then
Exit;
memo.Lines.Add('an exception occured: ' + task.FatalException.Message);
end;
The issue at this point is, that the exception is not assigned to IOmniTaskControl.FatalException and I have no clue why.
Maybe some of you guys have some ideas on what I am doing wrong. The whole VCL sampleproject may be found here: https://github.com/stackoverflow-samples/OTLTaskException
This is an abstraction layer problem. Parallel.ParallelTask stores threaded code exception in a local field which is not synchronized with the IOmniTaskControl.FatalException property. (I do agree that this is not a good behaviour but I'm not yet sure what would be the best way to fix that.)
Currently the only way to access caught exception of an IOmniParallelTask object is to call its WaitFor method. IOmniParallelTask should really expose a FatalException/DetachException pair, just like IOmniParallelJoin. (Again, an oversight, which should be fixed in the future.)
The best way to solve the problem with the current OTL is to call WaitFor in the termination handler and catch the exception there.
procedure TFormMain.HandleOnTaskThreadTerminated(const task: IOmniTaskControl);
begin
try
fTask.WaitFor(0);
except
on E: Exception do
memo.Lines.Add('an exception occured: ' + E.Message);
end;
CleanupTask;
end;
I have also removed the HandleOnTaskStop and moved the cleanup to the termination handler. Otherwise, fTask was already nil at the time HandleOnTaskThreadTerminated was called.
EDIT
DetachException, FatalException, and IsExceptional have been added to the IOmniParallelTask so now you can simply do what you wanted in the first place (except that you have to use the fTask, not task).
procedure TFormMain.HandleOnTaskThreadTerminated(const task: IOmniTaskControl);
begin
if not assigned(fTask.FatalException) then
Exit;
memo.Lines.Add('an exception occured: ' + FTask.FatalException.Message);
CleanupTask;
end;
EDIT2
As noted in comments, OnTerminate handler relates to one task. In this example this is not a problem as the code makes sure that only one background task is running (NumTasks(1)).
In a general case, however, the OnStop handler should be used for this purpose.
procedure TFormMain.btnExecuteTaskClick(Sender: TObject);
begin
if Assigned(fTask) then
Exit;
memo.Lines.Add('task has been started..');
fTask := Parallel.ParallelTask.NoWait.NumTasks(1);
fTask.OnStop(HandleOnStop);
fTask.Execute(TaskToExecute);
end;
procedure TFormMain.HandleOnStop;
begin
if not assigned(fTask.FatalException) then
Exit;
memo.Lines.Add('an exception occured: ' + FTask.DetachException.Message);
TThread.Queue(nil, CleanupTask);
end;
As HandleOnStop is called in a background thread (because NoWait is used), CleanupTask must be scheduled back to the main thread, as in the original code.

Scope of Application.OnException AND Delphi

I am a new programmer and trying to understand how Delphi's Application.OnException event works. A colleague has modified the default exception handling by creating his own method and instantiating it and passing it to Application.OnException in the initialization section of a unit. This unit is declared in the uses clause of another unit and otherwise unused.
unit ADLDebug;
...
class procedure TADLExceptionHandler.ADLHandleException (Sender: TObject; E: Exception);
...
initialization
Handler := TADLExceptionHandler.Create;
Application.OnException := Handler.ADLHandleException;
I can only step into the initialization section using the debugger, and not into the ADLHandleException method. I am trying to cause an exception in the code that will be caught by the redefined HandleException method.
Should the scope of the redefined HandleException method be only in the units that include ADLDebug? I was thinking that it should be application wide, but I can't seem to call it.
The scope of Application.OnException is indeed application wide. The event will fire whenever an exception is raised that is not handled.
You are failing to see the event fire because you are raising the exception at startup, before the message loop starts.

Exceptions on DBGrid editing

I have implemented an editable DBGrid. If a field is not filled correctly an exception is thrown and a message is shown, for example:
'08:00::00' is not a valid time
How can I catch those exceptions so that I can show messages written by me instead of the automatically generated ones? I would be thankful for any help.
As #teran pointed in his comment, the exception is raised by the TDataSet (or one of it's components) that is bind to the TDBGrid, or by the DB engine itself.
You can try to handle the TDataSet.OnPostError (see also OnUpdateError and OnEditError):
TDataSet.OnPostError: Occurs when an application attempts to modify or insert a record and
an exception is raised. Write an OnPostError event handler to handle
exceptions that occur when an attempt to post a record fails.
Note that you could always use Application.OnException global event handler to catch any EDBxxx exceptions in your application.
EDIT: The EConvertError exception is raised before any actual data modifications, or any Post operation by the TDateTimeField field i.e.:
0045af91 +085 Project1.exe SysUtils StrToDateTime <- EConvertError
004ab76a +042 Project1.exe Db TDateTimeField.SetAsString
004a9827 +007 Project1.exe Db TField.SetText
004a95d9 +029 Project1.exe Db TField.SetEditText
004d6448 +014 Project1.exe DBGrids TCustomDBGrid.UpdateData
004d087f +02b Project1.exe DBGrids TGridDataLink.UpdateData
004d599a +01a Project1.exe DBGrids TCustomDBGrid.MoveCol
StrToDateTime is throwing the exception inside TDateTimeField.SetAsString, not touching the data, and
the TDataSet.OnxxxError event handlers will not be fired at all.
So your choices are (test the application in release mode):
1.Intercept and handle EConvertError via Application.OnException.
2.Use TField.EditMask to restrict user input to a valid time format e.g. !90:00;1;_ or use inplace DateTimePicker editor inside your Grid. (and avoid catching this exception).
3.Override TDateTimeField: use persistent fields with your TDataSet and create an inter-poser class as such:
type
TDateTimeField = class(Db.TDateTimeField)
protected
procedure SetAsString(const Value: string); override;
end;
TForm1 = class(TForm)
...
procedure TDateTimeField.SetAsString(const Value: string);
begin
try
inherited SetAsString(Value);
except
on E: EConvertError do
begin
ShowMessage(E.Message);
Abort;
end;
end;
end;
If an exception is being raised then there should be two error messages being shown when run in the debugger. One of these will be caught by the debugger and the 2nd handled by the UI (when running your program as a user you will only see the 2nd).
The exception error message should have contain a string like
Appname.exe raised exception EExceptionName with message XXX
You will need to take note of EExceptionName.
Around the block of code creating the exception you will need to write
...
try
code that can cause the exception here
except
on e: EExceptionName do
begin
ShowMessage('Your apps nicer error message here');
end;
end;
note - if you don't make a call to exit; after handling an exception, your code will continue executing everything after your try..except block. Also, if there are many things that can cause the same error message in the same code block then you may not be able to write anything too specific. e.Message is a string that holds the message that is shown in the unhandled exception and may be useful to also present to the user.
Also try to move away from BDE - ADO is far better supported on modern systems.

Fatal application error not caught by MadExcept

I have an application which runs multiple threads. I use MadExcept to catch errors and debug it.
The problem is that sometimes after 2-3 hours of running, Windows shows a close program dialog. Why isn't that error handled by MadExcept ?
Threads are a special case. If you have an exception in a thread, it will not get handled by the global handler, and will usually kill your application. The solution is easy though, with madExcept. Just catch the exception, and tell MadExcept about it. It will log in the usual way, and you won't kill your thread.
uses
{$IFDEF MadExcept}
madExcept,
{$ENDIF}
procedure TMyThread.Execute;
begin
try
SetName;
// do your stuff
except
on errInfo : Exception do
begin
{$IFDEF MadExcept}
HandleException(etNormal, errInfo);
{$ENDIF}
end;
end;
end;
What I also do is have the thread set a "RunningOK" property to true when it starts, and the exception sets it to False. This way my control code can see that something went wrong, and handle that appropriately (either restart it, or report the error, etc)

Resources