Best Practice: Wann verwendet ihr Exceptions in Funktionen?

[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.

[Furtbichler]

Zitat von jaenicke:

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

Indem in der Division-Methode ein Logging eingebaut wird. Viel hilft es zwar nicht, denn man kann ja nur loggen: 'Bei der Division von 1.2345/0' ist ein Fehler aufgetreten.

Bei Delphi ist es ja auch nicht soo einfach, den Grund einer Fehlrechnung zu erkennen:

Delphi-Quellcode:

Try
  A:=B/C/D/E/F;
Except
  On EDivideByZero do
    // Soll ich hier C,D,E,F prüfen? Blödsinn
    // Also, was tun?
...

Manchmal ist ein Null-Objekt sinnvoll, manchmal nicht. Ich hatte neulich den Fall, das eine Bitmap skaliert werden sollte, also:
Function ScaleBmp (aBitmap : TBitmap; Width : Integer) : TBitmap; Was soll zurückkommen, wenn aBitmap=null? Fail-Fast sagt: Exception! Ich habe gesagt: Na ja... entweder eine leere Bitmap (h=b=0)oder Nil. Wenn ich letzteres verwende, muss ich aber mein gesamtes Framework auf den Sonderfall 'nil' umstellen, ginge, wäre aber blöd.

Wenn ich aber eine leere Bitmap nehme, kann ich transparent mit allen weiteren Methoden arbeiten, ohne auf Nil prüfen zu müssen, was den Code doch etwas unleserlich machen würde. Ich kann eine leere Bitmap skalieren (kommt eh ne leere Bmp raus), filtern, weichzeichnen, Kantenerkennung betreiben, speichern, laden, usw. usw.

Wenn ich einen Rand um eine leere Bmp zeichne, dann entsteht allerdings (je nachdem, ob ich das will) eine nichtleere Bmp oder wieder eine leere Bmp.

Noch ein Wort zu Exceptions. Wir verwenden Exceptions auch zur Validierung:

Delphi-Quellcode:

Procedure TStorage.Store (theObject : TSomeStuff);
Begin
  try
    theObject.Validate();
    Persist(theObject);
  Except
    On E:Exception Do HandleError(E);
  End
End;

Procedure TStorage.HandleError(E:Exception);
Begin
  If E is EValidationException then Raise; 

  If E is EPersitingException then begin
    Log('Probleme beim Speichern', E);
    Raise ECannotStoreException.Create('Speicherprobleme');
  end;
  
  if E is Exception then begin
    Log('Programmierfehler', E);
    Raise ECannotStoreException.Create('Programmierfehler');
  end;
end;

Alle Public-Methoden der TStorage-Klasse haben einen Try-Except-Wrapper, der HandleError aufruft. Alle Exceptions, mit Ausnahme der EValidationException, werden gekapselt.

Der Aufrufer muss dann nur die beiden Exceptions abfangen.

Bei einer Validation Exception weiß er dann, das er ne Meldung anzeigen kann und den Anwender die Chance gibt, seine Daten zu ändern.

Ansonsten kann nur eine ECannotStoreException auftreten. Die kann er auch auswerten und z.B. den Vorgang beenden, denn diese Exception bedeutet, das es (derzeit) nicht funktioniert. Konkret müsste man natürlich die genaue Fehlerursache ermitteln (indem der Persister z.B. geeignete Informationen bereitstellt).

Auf jeden Fall sieht der Validator immer gleich aus:

Delphi-Quellcode:

Procedure TSomeStuff.Validate;
Begin
  If SomeData<23 then Raise EValidationException.Create('SomeData too small');
...

Man kann hier auch mit Rückgabewerten arbeiten, aber wenn der Validator wieder andere Validatoren aufruft, wird das wieder nervig. Mit Exceptions bleibt der Code immer einfach zu lesen.

[Phoenix]

Zitat von Furtbichler:

Manchmal ist ein Null-Objekt sinnvoll, manchmal nicht. Ich hatte neulich den Fall, das eine Bitmap skaliert werden sollte, also:
Function ScaleBmp (aBitmap : TBitmap; Width : Integer) : TBitmap; Was soll zurückkommen, wenn aBitmap=null? Fail-Fast sagt: Exception! Ich habe gesagt: Na ja... entweder eine leere Bitmap (h=b=0)oder Nil. Wenn ich letzteres verwende, muss ich aber mein gesamtes Framework auf den Sonderfall 'nil' umstellen, ginge, wäre aber blöd.

Korrekt. Ich als .NET'ler überprüfe auch üblicherweise erstmal meine Argumente. In dem Fall würde ich auch gleich eine ArgumentNullException werfen. Wenn die Funktion nur in einem bestimmten Bereich skalieren kann, und width ausserhalb der validen Werte liegt, gibts auch gleiche ne ArgumentOutOfRangeException (oder eine mehr generische ArgumentException mit entsprechendem Fehlertext).

Sowas (= konkret eine Fehlbedienung) sollte maximal beim Entwickeln passieren und nicht im normalen Programmablauf. Und wenn doch, ist woanders was schief gelaufen (Ausnahmesituation) Da sind Exceptions natürlich das Mittel der Wahl.

[Der schöne Günther]

Und jetzt könnte man wieder wild darüber debatieren, ob der Aufrufer von ScaleBmp gezwungen sein sollte, die offensichtlich zu erwartenden EArgumentNull und EArgumentOutOfRange-Exception zu behandeln oder selbst kenntlich zu machen, dass er diese werfen könnte.

Macht das den Code lesbarer?

[Furtbichler]

Zitat von Der schöne Günther:

Und jetzt könnte man wieder wild darüber debatieren, ob der Aufrufer von ScaleBmp gezwungen sein sollte, die offensichtlich zu erwartenden EArgumentNull und EArgumentOutOfRange-Exception zu behandeln oder selbst kenntlich zu machen, dass er diese werfen könnte.

Ich habe eine ähnliche Debatte mit den Fail-Fast-Verfechtern gehabt. Man gewöhnt sich an den contract:

Delphi-Quellcode:

Procedure TMyStuff.ScaleBitmap(aBitmap : TBitmap...);
Begin
  CheckNull(aBitMap,'TMyStuff.ScaleBitmap: aBitmap');
  ...

Zitat von jaenicke:

Eine Bitmapreferenz, die nil ist, kann skaliert auch wieder eine nil-Referenz ergeben

Das ist schwierig, wenn Du auf Methoden der Bitmap zugreifen willst. Wobei Delphi da ja doch ziemlich robust ist ('if self=nil then return'). So gesehen, doch nicht so schwierig

[jaenicke]

Zitat von Phoenix:

Korrekt. Ich als .NET'ler überprüfe auch üblicherweise erstmal meine Argumente. In dem Fall würde ich auch gleich eine ArgumentNullException werfen.

Wobei man das auch anders argumentieren kann:
Eine Bitmapreferenz, die nil ist, kann skaliert auch wieder eine nil-Referenz ergeben ohne dass ein Fehler vorliegt. Wenn dieser Wert vorher erlaubt ist, warum sollte eine Skalierungsfunktion dann dieses Verhalten ändern? Denn ist es nicht erlaubt, hätte es bereits vorher geprüft werden müssen.

Insofern gibt es immer mehrere Möglichkeiten, die von den Vorgaben abhängen. Es sollte nur innerhalb einer Klassenbibliothek konsistent sein.

[Meflin]

Zitat von jaenicke:

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

Es hindert dich ja auch niemand daran, das Nullobjekt um beliebige Fehlerinformationen zu erweitern. Dann könntest du in diesem Fall, wenn du das denn wölltest, sogar konkret speichern, dass der Fehler genau bei der x-ten Berechnung aufgetreten ist. Und dann hast du schonmal deutlich mehr Infos, als mit dem äquivalenten Exception-Code (wie von Furtbichler gezeigt).

[Sir Rufo]

Zitat von Meflin:

Zitat von jaenicke:

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

Es hindert dich ja auch niemand daran, das Nullobjekt um beliebige Fehlerinformationen zu erweitern. Dann könntest du in diesem Fall, wenn du das denn wölltest, sogar konkret speichern, dass der Fehler genau bei der x-ten Berechnung aufgetreten ist. Und dann hast du schonmal deutlich mehr Infos, als mit dem äquivalenten Exception-Code (wie von Furtbichler gezeigt).

Allerdings hätte ich das Object als NaNComputation deklariert, weil es für diesen konkreten Fall benutzt wird.

Ob man Exceptions oder NullObjekt verwendet, hängt eben davon ab, ob es eine Ausnahme (falscher Zugriff) oder gewöhnlicher Anwendungsfall ist.

Exception weil ich die Grenzen beachten muss

Delphi-Quellcode:

type
  TMyList = class
    property Count;
    property Items[Index : Integer] : TItem read GetItem;
  end;

function TMyList.GetItems(Index : Integer) : TItem;
begin
  if Index >= Count then
    raise Exception;
  Result := ...
end;

NullObjekt

Im Hauptmenü gibt es den Menü-Punkt Drucken aber das Drucken wird nicht an jeder Stelle unterstützt (weil da gibt es nichts zum Drucken oder ist noch nicht implementiert oder das Druckmodul wurde nicht gekauft).
Die Aktion aus dem Hauptmenü holt sich trotzdem mit CommandHandler.Command['print'] den Eintrag und bekommt eben mal ein echtes Objekt oder eben das NullObjekt.

Exceptions wären hier kontraproduktiv und eine Überprüfung von aussen macht die Verdrahtung aufwendiger. Hier kann jeder beliebige Befehl im Menü verdrahtet werden und die Implementierung kann erfolgen wann will.

Delphi-Quellcode:

ICommand = interface
  function CanExecute : Boolean;
  procedure Execute;
end;

TCommandHandler = class
  property Command[const Name : string] : ICommand read GetCommand;
end;

function TCommandHandler.GetCommand( const Name : string ) : ICommand;
begin
  if not FCommands.Contains( Name ) then
    Result := NullComand.Create
  else
    Result := FCommands[Name];
end;

NullCommand = class( TInterfacedObject, ICommand )
  function CanExecute : Boolean;
  procedure Execute;
end;

function NullCommand.CanExecute : Boolean
begin
  Result := False;
end;  

procedure NullCommand.Execute;
begin
end;