Best Practice: Wann verwendet ihr Exceptions in Funktionen?

[Sir Rufo]

Mit Exceptions wird zudem der Code in der Regel kompakter und übersichtlicher.

Beispiel ohne Exceptions:

Delphi-Quellcode:

procedure foo;
var
  LHandle1, LHandle2, LHandle3, LHandle4 : THandle;
begin
  LHandle1 := GetHandleFromElsewhere;
  if LHandle1 <> INVALID_HANDLE then
  begin
    LHandle2 := GetHandleFromElsewhere( LHandle1 );
    if LHandle2 <> INVALID_HANDLE then
    begin
      LHandle3 := GetHandleFromElsewhere( LHandle2 );
      if LHandle3 <> INVALID_HANDLE then
      begin
        LHandle4 := GetHandleFromElsewhere( LHandle3 );
        if LHandle4 <> INVALID_HANDLE then
        begin
          DoSomethingWithHandles( LHandle1, LHandle2, LHandle3, LHandle4 );
        end;
      end;
    end;
  end;
end;

Jetzt mal mit Exceptions

Delphi-Quellcode:

type 
  EInvalidHandleException = class( Exception );

procedure CheckInvalidHandle( AHandle : THandle; const AText : string );
begin
  if AHandle = INVALID_HANDLE then
    raise EInvalidHandleException.Create( AText );
end;

procedure foo;
var
  LHandle1, LHandle2, LHandle3, LHandle4 : THandle;
begin
  LHandle1 := GetHandleFromElseWhere;
  CheckInvalidHandle( LHandle1, 'from ElseWhere' );

  LHandle2 := GetHandleFromElseWhere( LHandle1 );
  CheckInvalidHandle( LHandle2, 'from ElseWhere' );

  LHandle3 := GetHandleFromElseWhere( LHandle2 );
  CheckInvalidHandle( LHandle3, 'from ElseWhere' );

  LHandle4 := GetHandleFromElseWhere( LHandle3 );
  CheckInvalidHandle( LHandle4, 'from ElseWhere' );

  DoSomethingWithHandles( LHandle1, LHandle2, LHandle3, LHandle4 );
end;

[himitsu]

Zitat von Sir Rufo:

Mit Exceptions wird zudem der Code in der Regel kompakter und übersichtlicher.

Ja, das schon, aber nur solange recht "selten" mal ein Handle nicht geliefert werden konnte.

Wobei du aber auch die Funktionsweise von foo geändert hast.
Beim ersten foo, mit den IFs, bekommt keiner mit, ob DoSomethingWithHandles verarbeitet wurde.

[Meflin]

Zitat von Sir Rufo:

Mit Exceptions wird zudem der Code in der Regel kompakter und übersichtlicher.

Beispiel ohne Exceptions:
... Jetzt mal mit Exceptions
...

Na sorry aber das ist ja jetzt Äpfel mit Birnen verglichen. Das Beispiel ohne Exceptions kann man genauso leserlich und ohne verschachtelte ifs aufschreiben und trotzdem keine Exceptions verwenden... indem man einfach Guard Clauses benutzt. Soll heißen:

Code:

procedure foo;
var
  LHandle1, LHandle2, LHandle3, LHandle4 : THandle;
begin
  LHandle1 := GetHandleFromElsewhere;
  if LHandle1 = INVALID_HANDLE then return;
  
  LHandle2 := GetHandleFromElsewhere(LHandle1);
  if LHandle2 = INVALID_HANDLE then return;
  ...
end;

Persönlich bin ich nicht von der Notwendigkeit von Exceptions überzeugt. Vor allem finde ich, dass die Exceptionbehandlung in den meisten Sprachen (auch in Delphi) nicht wirklich schön lesbarer Code ist.

[JasonDX]

Zitat von Meflin:

Code:

procedure foo;
var
  LHandle1, LHandle2, LHandle3, LHandle4 : THandle;
begin
  LHandle1 := GetHandleFromElsewhere;
  if LHandle1 = INVALID_HANDLE then return;
  
  LHandle2 := GetHandleFromElsewhere(LHandle1);
  if LHandle2 = INVALID_HANDLE then return;
  ...
end;

Persönlich bin ich nicht von der Notwendigkeit von Exceptions überzeugt. Vor allem finde ich, dass die Exceptionbehandlung in den meisten Sprachen (auch in Delphi) nicht wirklich schön lesbarer Code ist.

In diesem Beispiel sind Exceptions tatsächlich nicht notwendig, denn der Fall der geprüft wird, wird nicht direkt als Fehlerfall gehandhabt wird. Aber: Nehmen wir an, die Methode hat als Voraussetzung, dass alle 4 Handles gegeben sind. Wie sieht dann die If-Abfrage aus, bzw. wie wird dem Aufrufer am besten mitgeteilt, dass die Daten, die übergeben wurden, nicht valide waren?

Für den Fall, dass eine Methode einen Fehlerfall nicht korrekt behandeln kann, sind Exceptions ein valider, sauberer und sinnvoller Weg.

[Meflin]

Zitat von JasonDX:

Für den Fall, dass eine Methode einen Fehlerfall nicht korrekt behandeln kann, sind Exceptions ein valider, sauberer und sinnvoller Weg.

Exceptions sind für mich dann akzeptabel, wenn man andernfalls mehr als einen Rückgabetyp verwenden müsste (geht in statisch getypten Sprachen sowieso nicht) und man keine bessere Alternative hat. Ein Beispiel dafür wäre z.B. eine Try-Klasse. Keine Ahnung, ob es sowas in Delphi gibt. Ist aber auch egal, denn das ist eine "total normale" Klasse und nicht durch spezielle Syntax eingeführt. Wenn man also Try als Typen hat, kann das Ergebnis entweder eine Instanz von Failure oder von Success sein, und beide Wrappen jeweils entweder den Fehler oder das Ergebnis. Muss man nicht gut finden, aber drüber nachdenken kann man ja mal (on a related note: Ich finde auch das procedure-Konzept nicht wirklich sinnvoll )

Exceptions sind mir persönlich einfach zu low level Ich meine, wozu denkt man sich von der technischen Ebene völlig abstrahierte Konzepte wie OOP aus, wenn man dann doch wieder auf etwas zurückgreift, was doch sehr von der Hardware-Ebene inspieriert anmutet (Interrupts...).

Edit: ein anderes Beispiel wäre das Null-Objekt Pattern. Viel schöner als Fehlerbehandlungscode ist doch, wenn man einfach mit den Objekten arbeiten kann, die man als Rückgabe bekommt, und einfach genau das passiert, was passieren soll, wenn man Methoden dieser Objekte aufruft.

[JasonDX]

Zitat von Meflin:

Exceptions sind für mich dann akzeptabel, wenn man andernfalls mehr als einen Rückgabetyp verwenden müsste (geht in statisch getypten Sprachen sowieso nicht) und man keine bessere Alternative hat. Ein Beispiel dafür wäre z.B. eine Try-Klasse. Keine Ahnung, ob es sowas in Delphi gibt. Ist aber auch egal, denn das ist eine "total normale" Klasse und nicht durch spezielle Syntax eingeführt. Wenn man also Try als Typen hat, kann das Ergebnis entweder eine Instanz von Failure oder von Success sein, und beide Wrappen jeweils entweder den Fehler oder das Ergebnis. Muss man nicht gut finden, aber drüber nachdenken kann man ja mal

Mal abgesehen davon, dass der Code IMO schnell sehr unleserlich wird, was würde denn passieren, wenn ich im Fehlerfall versuche, aufs Success-Objekt zuzugreifen? Krieg ich dann wieder ein Try-Objekt mit Failure? Oder null? (Leider) lässt sich nicht alles aus Funktionalen Sprachen auf objektorientierte oder prozedurale Sprachen mappen. Vor allem wenn die Idee erst schon aus diesen Konzepten kommt und ins Funktionale übertragen wurde.

Zitat von Meflin:

Exceptions sind mir persönlich einfach zu low level Ich meine, wozu denkt man sich von der technischen Ebene völlig abstrahierte Konzepte wie OOP aus, wenn man dann doch wieder auf etwas zurückgreift, was doch sehr von der Hardware-Ebene inspieriert anmutet (Interrupts...).

Da denkst du einfach nur das Falsche, wenn du an Exceptions denkst. Die haben in ihrer Definition gleich viel mit Interrupts zu tun wie eine Applikation im Lambda-Kalkül mit nem call der CPU.
Ich denke kein Stück an Interrupts wenn ich eine Exception schmeiße, sondern daran, das gerade ein besonderer Fall in meinem Code aufgetreten ist, den ich in meiner derzeitigen Methode nicht behandeln kann.

Zitat von Meflin:

Edit: ein anderes Beispiel wäre das Null-Objekt Pattern. Viel schöner als Fehlerbehandlungscode ist doch, wenn man einfach mit den Objekten arbeiten kann, die man als Rückgabe bekommt, und einfach genau das passiert, was passieren soll, wenn man Methoden dieser Objekte aufruft.

Das spricht doch eigentlich gegen eine Try-Klasse und für Exceptions nehmen wir an ich habe eine Methode

Code:

parseUrl(String): Url

Wenn ich mit Exceptions arbeite weiß ich, dass wenn ich bspw.

Code:

myUrl = parseUrl(input);

aufrufe und keine Exception geworfen wird (und myUrl somit als zugewiesen gilt), ich in myUrl eine wunderschöne Url-Instanz habe. Wenn ich hingegen eine Try-Klasse oder Fehlermeldungen durch Rückgabewerte oder CallByReference-Parameter verwende, was habe ich dann in myUrl? Vielleicht ne Url, vielleicht aber auch nicht.

[Sir Rufo]

Zitat von JasonDX:

Zitat von Meflin:

Edit: ein anderes Beispiel wäre das Null-Objekt Pattern. Viel schöner als Fehlerbehandlungscode ist doch, wenn man einfach mit den Objekten arbeiten kann, die man als Rückgabe bekommt, und einfach genau das passiert, was passieren soll, wenn man Methoden dieser Objekte aufruft.

Das spricht doch eigentlich gegen eine Try-Klasse und für Exceptions nehmen wir an ich habe eine Methode

Code:

parseUrl(String): Url

Wenn ich mit Exceptions arbeite weiß ich, dass wenn ich bspw.

Code:

myUrl = parseUrl(input);

aufrufe und keine Exception geworfen wird (und myUrl somit als zugewiesen gilt), ich in myUrl eine wunderschöne Url-Instanz habe. Wenn ich hingegen eine Try-Klasse oder Fehlermeldungen durch Rückgabewerte oder CallByReference-Parameter verwende, was habe ich dann in myUrl? Vielleicht ne Url, vielleicht aber auch nicht.

Ein Null-Objekt setzt man auch nicht ein, um eine Exception-Behandlung zu ersetzen, sondern, da wo es passt, um den Code einfacher zu halten.

Denn ständig zu prüfen, ob es das Objekt gibt oder nicht um, wenn ja, es dann zu benutzen ist dann etwas umständlich.

Vor allem, wenn dann dieses Objekt auch noch von aussen angesprochen werden soll.

Delphi-Quellcode:

ILogger = interface
  procedure Log( const Text : string );
end;

TFoo = class
private
  FLogger : ILogger;
  function GetLogger : ILogger;
  procedure SetLogger( const Value : ILogger );
public
  property Logger : ILogger read Getlogger write SetLogger;

  procedure Bar;
end;

implementation

type
  TNullLogger = class( TInterfacedObject, ILogger )
    procedure Log( const Text : string );
  end;

procedure TNullLogger.Log( const Text : string );
begin
  // do nothing
end;

procedure TFoo.SetLogger( const Value : ILogger );
begin
  FLogger := Value;
end;

function TFoo.GetLogger : Ilogger;
begin
  if not Assigned( Flogger ) then
    FLogger := TNullLogger.Create;
  Result := Flogger;
end;

procedure TFoo.Bar;
begin
  Logger.Log( 'Bar from TFoo Start' );
  Logger.Log( 'Bar from TFoo Step 1' );
  Logger.Log( 'Bar from TFoo Step 2' );
  Logger.Log( 'Bar from TFoo Step 3' );
  Logger.Log( 'Bar from TFoo Stop' );  
end;

end.

Als Logger kann ich jetzt also irgendwas dort unterjubeln, allerdings kann ich zum Ausschalten des Loggens einfach ein nil übergeben, und trotzdem knallt es nicht, es wird aber auch nichts geloggt.

[Meflin]

Zitat von JasonDX:

was würde denn passieren, wenn ich im Fehlerfall versuche, aufs Success-Objekt zuzugreifen? Krieg ich dann wieder ein Try-Objekt mit Failure? Oder null?

Das hast du falsch verstanden. Das ist so garnicht möglich. Du hast als Rückgabe z.B. ein Try[Int]. Dann ist das entweder ein Failure oder ein Success Objekt. Die konkrete Weiterverwendung ist dann sehr stark abhängig vom spezifischen Anwendungsfall. Aber du kannst mit dem Objekt erstmal weiterarbeiten, ohne zu wissen, was von beiden es ist. Also z.B.

Code:

maybeInt.map(x => x * 2)

Die Überprüfung, ob die ganze Geschichte erfolgreich war, musst du genau ein mal machen, nämlich zum Schluss, genau dann, wenn du das Endergebnis brauchst. Da man mehrere Trys auf diese Weise problemlos verketten kann, sparst du dir da SEHR VIEL Fehlerbehandlungscode.

Zitat:

(Leider) lässt sich nicht alles aus Funktionalen Sprachen auf objektorientierte oder prozedurale Sprachen mappen. Vor allem wenn die Idee erst schon aus diesen Konzepten kommt und ins Funktionale übertragen wurde.

Ist richtig, aber dieser Fall hat nicht sonderlich viel mit funktionaler Programmierung zu tun (außer der Verwendung von Lambdas, die immer nützlich sind).

Zitat:

Da denkst du einfach nur das Falsche, wenn du an Exceptions denkst. Die haben in ihrer Definition gleich viel mit Interrupts zu tun wie eine Applikation im Lambda-Kalkül mit nem call der CPU.

Ist mir schon klar, dass das nichts mit Interrupts zu tun hat. Was ich meinte war das Konzept "ich breche einfach mal mitten drin komplett ab, egal was ich gerade mache, und springe zu einer völlig anderen Codestelle", was beide durchaus gemeinsam haben.

Zitat von Meflin:

Das spricht doch eigentlich gegen eine Try-Klasse und für Exceptions

Das spricht absolut gegen Exceptions. Nehmen wir doch mal als Beispiel Division durch 0, was prinzipiell ja ein valider Anwendungsfall für Exceptions ist. Kann ich aber auch mit einem Nullobjekt lösen (Pseudocode):

Code:

interface IComputation {
  function currentValue: Float;
  function multiplyBy(other: Float): IComputation;
  function divideBy(other: Float): IComputation;
}

class Computation extends IComputation {
  
  function divideBy(other: Float): IComputation {
    if (other = 0) return new NullComputation();
    return new Computation(this.currentValue / other);
  }
  ...

}

class NullComputation extends IComputation {
  function currentValue: Float { return Float.NaN }
  function divideBy(other: Float): IComputation { return this; }
  ...
}

new Computation(5).divideBy(3).divideBy(0).divideBy(5).currentValue => NaN

[jaenicke]

Zitat von Meflin:

Das spricht absolut gegen Exceptions. Nehmen wir doch mal als Beispiel Division durch 0, was prinzipiell ja ein valider Anwendungsfall für Exceptions ist. Kann ich aber auch mit einem Nullobjekt lösen (Pseudocode):

Code:

new Computation(5).divideBy(3).divideBy(0).divideBy(5).currentValue => NaN

In dem Beispiel fehlt noch die Behandlung welche Division fehlgeschlagen ist. Wie das da schön geht, erschließt sich mir nicht.