Resetting the OnLostConnetion exception

[stoffman]

As a consumer of ZAbstractConnection I cannot prevent the exception of OnLostConnection from being raise, although I have a event handler to handle it. This forces me to handle the state of losing connection twice, first in the event handler and again in the function that led to this code path (handing the exception)

Can that be changes?


The following code is from the ZAbstractConnection unit

Code: Select all

procedure TZAbstractConnection.ConnectionLost(var AError: EZSQLConnectionLost);
var Err: EZSQLConnectionLost;
begin
  Err := AError;
  AError := nil;
  try
    CloseAllLinkedComponents;
  except end;
  try
    if Assigned(FOnLost) then
      FOnLost(Self); { I think the Err variable should be passed here}
  finally
    if Err <> nil then
      raise Err;
  end;
end;

[aehimself]

To be honest this code looks perfectly fine to me, I would not change it. Just do a check in your exception handler and if it's the connectionlost -> don't do anything.
Or remove your code from the OnConnectionLost handler.

[marsupilami]

Honestly I think that we could think about having a parameter like Handeled where true would indicate that everything is fine and we don't need to raise an exception and false means that we should raise an exception. Another option would be to name the paramaeter RaiseEcception and set it to rue by default...

But that is just an opinion. The decision is with Egonhugeist.

[stoffman]

@aehimself

Serious question, what is the point of having an event handler if you *must* also catch the exception? everything I can do in the event handler I can do in exception handler but not vice versa.

[aehimself]

Serious question, what is the point of having an event handler if you *must* also catch the exception? everything I can do in the event handler I can do in exception handler but not vice versa.

While I see your point (and it is perfectly valid I must add!) I always considered these event handlers as "notifications" for your program (so you can change an icon of a tabsheet, disable controls, etc.), the code flow is always Try .. Except .. End in my opinion. An exception is what Jan just mentioned - if you have a Var parameter to notify the component.
In 99% of the cases I'm creating Zeos's components runtime in worker threads and I design my program flow with exceptions included... therefore I never used ANY event handlers up until now.

The exception raised in the code is probably a part of the design as ANY workflow must be broken if the connection is broken.