Hey Mickmack,
Wenn Du ohnehin eigene
Exception-Typen definierst, um unabhängig von den spezifischen SQLExceptions oder IOExceptions zu sein und abstraktare, der wirklichen Aufgabe entsprechenden Excpeptions zu werfen, dann bietet sich ein Basistyp zB
Delphi-Quellcode:
EMyException =
class(
Exception)
public
procedure HandleError;
virtual;
abstract;
end;
an, von Dem Du dann erbst und die Methode
HandleError überschreibst, zB
Delphi-Quellcode:
EMyOpenFile = class(EMyException)
public
procedure HandleError;override;
end;
Der Entsprechde
Try..Except-Block könnte dann so aussehen
Delphi-Quellcode:
try
DoSth;
except
on E:EMyException
do HandleException(E);
on E:
Exception do raise EMyUnknownException.CreateChained(E);
end;
mit der Methode
Delphi-Quellcode:
procedure TMyClass.HandleException(const AnException: EMyException);
begin
Assert(Assigned(AnException));
AnException.HandleException;
end;
Die wirkliche Verarbeitung geschieht dann in der jeweiligen Implementierung von
HandleException, also zB
EMyOpenFile.HandleException,
EMyReadFile.HandleException, etc. mithilfe von Polymorphie.
Etwas unglücklich an dieser Lösung ist die Tatsache, dass die wirkliche Handlung (zB der Aufruf von
ShowMessage) direkt in der Klasse wäre und damit unflexibel ist. Zur Lösung empfehle ich Dir hier das sog. "Visitor Pattern [Gamma et. al.]"
delphi AND visitor AND pattern.
Eine lesenswerte Serie über Exceptions (allerdings in Java) stammt von
Brian Goetz, Exceptional practices, Part 1-3.
HTH