Habe vor einiger Zeit einen interessanten Artikel zum Thema Fail Fast , von Jim Shore / Martin Fowler gefunden, den ich jedem Entwickler ans Herz legen möchte.
Darin werden die Kernpunkte der “Fail Fast” Strategie recht gut auf den Punkt gebracht: Code sollte bei Fehlern so bald wie möglich Alarm-Schlagen anstatt Fallbacks und Defaultwerte zu verwenden. Das Beispiel aus dem Artikel sieht wie folgt aus:
public int maxConnections() {
String property = getProperty(“maxConnections”);
if (property == null) {
return 10;
}
else {
return property.toInt();
}
}
Hier wird, wenn ein Pflichtfeld fehlt, ein Defaultwert verwendet. Das sieht sinnvoll aus und soll die Anwendung robust machen, impliziert aber auch einige Probleme.
Angenommen ein Administrator hat vergessen, die entsprechende Property zu setzen, die Anwendung läuft aber. Vielleicht mit einem kleinen Hinweistext in den Logs, aber wer liest schon die Logs beim Applikationsstart. Da alles läuft, würde er sicherlich davon ausgehen, dass alles in Ordnung ist.
Erst nach einiger Laufzeit gibt es Performanzprobleme auf den Produktivsystemen, die als Bug-Meldung an den Entwickler zurückkommen und dort erst dazu führen, dass das Problem geklärt wird. Denn für die Produktion hätte der Wert höher gewählt werden müssen.
An dieser Stelle wäre es wahrscheinlich sinnvoller gewesen, wenn der Code auf den Missstand hingewiesen und den Betrieb verweigert hätte. So wäre bereits zu einem viel früheren Zeitpunkt bemerkt worden, dass die Einstellung fehlt / vergessen wurde.
Eine Fail Fast Version der Methode würde dann wie folgt aussehen:
public int maxConnections() {
String property = getProperty(“maxConnections”);
if (property == null) {
throw new IllegalArgumentException(“maxConnections property not found in “ + this.configFilePath);
}
else {
return property.toInt();
}