Fehlerbehandlung : Folgefehler ?

[himitsu]

Moin,

sowas ist mir schon mehrmals untergekommen, daß ein Folgefehler die eigentliche Fehlermeldung geschrottet hat.
Jetzt hab ich das nochmal und konnte diesmal den Verursacher rausfinden.

Sollte man nun Folgefehler beachten, oder nicht?
Eigentlich muß man ja nur den ersten Fehler behandeln und der Zweite ist auch weg, bzw. man müsste den ersten Fehler erstmal kennen, was schwerer wird, wenn der sich in einer größeren Funktion versteckt und man durch den Folgefehler nicht das Wo erkennen kann.

[blabla]
GridFilter werden gespeichert, später wieder geladen und können zwischen den Installationen synchronisiert werden.
Die Spalten im Grid werden aus dem DataSet generiert und die Query kann über die Synchro angepasst werden.
Der Filter greift nun auf eine Spalte zu, welche es inzwischen nicht mehr gibt.

Beim Laden des Filters knallt es nun in ReadComponent (Column fehlt und Property kann nicht geladen werden)
und beim Filter.EndUpdate oder Active=True wird auch nochmal auf diese (nichtexstierende=nil) Column zugegriffen und es knallt nochmal.
[/blabla]

Delphi-Quellcode:

//procedure TcxFilterCriteria.LoadFromStream(Data);
Filter.EndUpdate
GridView.DataController.Filter.BeginUpdate;
try
  Wrapper := TFilterWrapper.Create(nil);
  try
    Wrapper.Filter := GridView.DataController.Filter;
    Data.ReadComponent(Wrapper);  ///// Stream-Lesefehler /////
  finally
    Wrapper.Free;
  end;
finally
  GridView.DataController.Filter.EndUpdate;  ///// Zugriffsverletzung /////
end;

Der Kunde und auch wir sehen also erstmal nur das "Zugriffsverletzung"

Die aktuelle Lösung besteht nun also darin den Folgefehler zu unterdrücken.

Delphi-Quellcode:

//GridView.DataController.Filter.LoadFromStream(Data);
{$REGION 'TcxFilterCriteria.LoadFromStream'}
// Am Ende von TStream.ReadComponent wird aus einem "Fehler beim Lesen von _1.Filter.Criteria: Stream-Lesefehler"
// in TcxFilterCriteria.EndUpdate ein nichtssagendes "Zugriffsverletzung bei Adresse 0".
Filter.EndUpdate
GridView.DataController.Filter.BeginUpdate;
try
  Wrapper := TFilterWrapper.Create(nil);
  try
    Wrapper.Filter := GridView.DataController.Filter;
    Data.ReadComponent(Wrapper);
  finally
    Wrapper.Free;
  end;
finally
  //GridView.DataController.Filter.EndUpdate;
  if System.ExceptObject = nil then
    GridView.DataController.Filter.EndUpdate
  else
    try  GridView.DataController.Filter.EndUpdate;  except end;  // tritt hier ein Folgefehler auf, dann würde die originale Fehlermeldung geschrottet.
end;
{$ENDREGION}
GridView.DataController.Filter.Active := True;

Delphi-Quellcode:

procedure TcxFilterCriteria.LoadFromStream(AStream: TStream);
var
  AWrapper: TFilterWrapper;
begin
  BeginUpdate;
  try
    AWrapper := TFilterWrapper.Create(nil);
    try
      AWrapper.Filter := Self;
      AStream.ReadComponent(AWrapper);
    finally
      AWrapper.Free;
    end;
  finally
    if System.ExceptObject = nil then
      EndUpdate
    else
      try  EndUpdate;  except end;  // tritt hier ein Folgefehler auf, dann würde die originale Fehlermeldung geschrottet.
  end;
end;

Oder vielleicht besser gleich auch für alle anderen Codestellen?

Delphi-Quellcode:

procedure TcxFilterCriteria.EndUpdate;
begin
  Dec(FLockCount);
  if System.ExceptObject = nil then
    CheckChanges
  else
    try  CheckChanges;  except end;  // tritt hier ein Folgefehler auf, dann würde die originale Fehlermeldung geschrottet.
end;

Als Pattern also irgendwie so?

Delphi-Quellcode:

procedure TMyClass.EndUpdate;
var
  HasError: Boolean;
begin
  HasError := System.ExceptObject <> nil;
  try
    ....
  except
    if not HasError then
      raise;
  end;
end;

////////////////////////////////////////////////////////////////

procedure TMyClass.EndUpdate;
begin
  try
    ....
  except
    if not Assigned(PRaiseFrame(RaiseListPtr)^.NextRaise) then  // Kürzer, aber funktioniert nicht bei PC_MAPPED_EXCEPTIONS
      raise;
  end;
end;

Im Grunde müsste man jetzt noch bestimmte Sonderfälle beachten, wenn man eine allgemeine Lösung sucht, was aber bei uns erstmal nicht vorkommt.

• Abort, bzw. EAbort
• Und falls der Compiler den JMP von Exit oder Break in eine stille Exception optimiert. (z.B. beim Rausspringen aus einem Try-Except/Finally-Blocks)
• ... i glob dat war's