schönes Programmieren: Validierungen

[minzee]

Hi

Ich hatte heute ein interessantes Buch in der Hand. Es ging darum, wie man schön Programmiert. Leider war das alles nur ziemlich theorietisch.

Wie würdet ihr z. B. Validierungen programmieren?

Ein Datum data könnte einer Klasse C zugeordnet sein:

public class C
{
   private int data;
   
   public static boolean isValidData(int data)
   {
      return data >= 0;
   }
   public void setData(int data) throws Exception
   {
      if(!isValidData(data))
      {
         throws new Exception("data");
      }
      this.data = data;
   }
   public int getData()
   {
      return data;
   }
}

Die Daten könnten aus unterschiedlichsten Datenquellen stammen. Z. B. aus einem Formular:

public class Form
{
   const int VALID = 0;
   const int INVALID = 1;
   const int NOT_A_NUMBER = 2;
   const int EMPTY = 3;
   
   public boolean isValidData(string stringData)
   {
      if(stringData == "") 
      {
         return EMPTY; // Pflichtfeld im Formular
      }
      try
      {
         int intData = Integer.parseInt(stringData);
         return C.isValidData(intData) ? VALID : INVALID;
      }
      catch(NumberFormatException e)
      {
         return NOT_A_NUMBER;
      }
   }
}

Würdet ihr das auf diese Weise programmieren?

 

[Agaton Sax]

Nein, für Argumentvalidierungen solltest du passende RuntimeExceptions werfen z.B. NPE oder IAE, und diese natürlich mit einer aussagekräftigen Message versehen, und nicht mit "data". Außerdem gibts für sowas schon fertige Libs z.B. Preconditions (Guava: Google Core Libraries for Java 19.0-SNAPSHOT API)

 

[minzee]

Exceptions darf man nur werfen, wenn ein Ausnahmefall eintritt. Das ist beim Ausfüllen von Formularen nicht gegeben. Es ist kein Ausnahmefall, wenn ein User ein Pflichtfeld nicht ausfüllt.

 

[Agaton Sax]

Meine Antwort bezog sich auf das Datenobjekt und die Argumentvalidierung innerhalb des Setters. Nicht auf irgendwelche Formular-Validierungen die obendrüber liegen.

 

[minzee]

OK

Wie würde dann bei dir das Programm aussehen? Muss nicht funktionieren, kann ruhig Syntaxfehler beinhalten. Geht nur ums Prinzip.

 

[Agaton Sax]

public void setData(int data) {
    Preconditions.checkArgument(data >= 0, "data must not be negative");
    this.data = data;
}

bzw. händisch:

public void setData(int data) {
    if (data < 0) {
        throw new IllegalArgumentException("data must not be negative");
    }
    this.data = data;
}

 

[minzee]

Achso, ich dachte schon, du würdest noch irgendwelche zusätzlichen Exceptions einbauen wollen.

 

[Saheeda]

@Agaton Sax

Vielleicht auch mehr n philosophisches Problem:
Hier im Forum habe ich schon häufiger den Satz gelesen: "Exceptions sollten nicht der Programmsteuerung dienen."
Wäre zur Validierung da nicht z.B. ein boolscher Wert besser?

Sollten Exceptions nicht nur geworfen werden, wenn wirklich schwerwiegende Probleme (Daten nicht gefunden, Pfade falsch, Verbindung unterbrochen) auftreten? N negatives Alter z.B. ist zwar doof, würde ich aber nicht als schwerwiegendes Problem bezeichnen.

 

[minzee]

Wenn etwas passiert, was nicht passieren soll, obwohl man entsprechende Prüfmöglichkeiten anbietet, dann sollte meiner Meinung nach eine Exception geworfen werden. In der Raumfahrt könnte so ein Fehler fürchterliche Auswirkungen haben. Womöglich würde eine Raumsonde dann in die entgegengesetzte Richtung fliegen

 

[Thallius]

Wenn etwas passiert, was nicht passieren soll, obwohl man entsprechende Prüfmöglichkeiten anbietet, dann sollte meiner Meinung nach eine Exception geworfen werden. In der Raumfahrt könnte so ein Fehler fürchterliche Auswirkungen haben. Womöglich würde eine Raumsonde dann in die entgegengesetzte Richtung fliegen

Na da ist es natürlich super wenn die Software der Raumsonde eine Exception wirft und mit einem stacktrace aussteigt.
Also eine dümmeres Beispiel gibt es wohl kaum.

Eine Exception sollte wirklich nur dann geworfen werden wenn es keine Möglichkeit gibt den Fehler abzufangen. Wenn der User etwas falsches eingibt, dann ist das keine Exception sondern dann kann man den User darüber informieren und auffordern das richtige einzugeben und das solange bis er das auch tut.

Genauso kann man viele Fehler mit einer Vernünftigen fehlerbehandlung abfangen. Dafür muss man sich aber Gedanken machen und u.u. Viel Code schreiben. DaZu sind die meisten schlicht und einfach zu faul. Eine Exception zu werfen ist ja viel einfacher und. Der User kann ja die Software einfach neu starten nach dem Crash. Wen interessierte.

Gruß

Claus

 

[Agaton Sax]

@Agaton Sax

Vielleicht auch mehr n philosophisches Problem:
Hier im Forum habe ich schon häufiger den Satz gelesen: "Exceptions sollten nicht der Programmsteuerung dienen."
Wäre zur Validierung da nicht z.B. ein boolscher Wert besser?

Von Fluent Interfaces abgesehen haben Setter im Normalfall keinen Rückgabewert. Ich sehe da auch keinen Missbrauch als Programmsteuerung, sondern es ist nun mal das etablierte Vorgehen bei Settern, die reingegebenen Daten zu überprüfen und nicht stillschweigend nichts zu tun oder gar den Objektzustand zu korrumpieren. Der Aufrufer sollte eher dafür sorgen, dass er keinen offensichtlichen Müll in den Setter reingibt. Und genau da kommt die von dir genannte Validierung ins Spiel. Aber eben zwischen Nutzereingabe und möglichem Aufruf des Setters, und nicht erst im Setter.

 

[minzee]

isValidData von Form sollte man noch umbenennen. Es liefert kein boolean wie die gleichnamige Methode in C, sondern einen int-Code. Also ist vielleicht validateData besser.

 

[Java20134]

Zur ersten Antwort:
Es ist schon richtig, dass man die Libs benutzt. Ich finde es aber ziemlich sinnvoll, die Libs auch mal teilweise selbst zuschreiben, um zu sehen, was da überhaupt passiert!

 

[minzee]

Ich glaube, das ist noch nicht schön programmiert. Momentan schaut es folgendermaßen aus:

/**
 * Model-Klasse.
 * Nimmt ein Datum auf, das zuvor validiert werden muss.
 * Sollte ein invalides Datum übergeben werden, wird eine Exception geworfen.
 * Zum Validieren wird eine statische Methode bereitgestellt.
 */
public class C
{
   private int data;
   
   /**
    * Prüft die Gültigkeit des Datums.
    * @param int data
    * @throws IllegalArgumentException
    */
   public static boolean isValidData(int data)
   {
      return data >= 0;
   }
   /**
    * Setzt das Datum.
    * @param int data
    * @throws IllegalArgumentException
    */
   public void setData(int data) throws IllegalArgumentException
   {
      if(!isValidData(data))
      {
         throw new IllegalArgumentException("data");
      }
      this.data = data;
   }
   /**
    * Gibt das Datum zurück.
    * @param int
    */
   public int getData()
   {
      return data;
   }
}

/**
 * Müssen alle Klassen implementieren, die ein DAtum validieren.
 */
public interface Source
{
   public static final int VALID = 0;
   public static final int INVALID = 1;
   public static final int NOT_A_NUMBER = 2;
   public static final int EMPTY = 3;
   
   public int validateData(String stringData);
}

/**
 * Formular-Klasse.
 */
public class Form implements Source
{
   /**
    * Prüft, ob im Formular ein gültiges Datum eingegeben wurde.
    * @param String stringData
    * @return int Ergebnis der Prüfung.
    */
   public int validateData(String stringData)
   {
      if(stringData == "") 
      {
         return EMPTY;
      }
      try
      {
         int intData = Integer.parseInt(stringData);
         return C.isValidData(intData) ? VALID : INVALID;
      }
      catch(NumberFormatException e)
      {
         return NOT_A_NUMBER;
      }
   }
}

public class Main
{
   public static void main(String[] args)
   {
      String data = "123"; 
      
      Form form = new Form();
      switch(form.validateData(data))
      {
         case Form.VALID:
            C c = new C();
            try
            {
               c.setData(Integer.parseInt(data));
               System.out.println("data " + c.getData() + " ist eine gültige Zahl");
            }
            catch(NumberFormatException e)
            {
               System.out.println("Programmierfehler: parseInt wirft Exception trotz vorhergehender Validierung");
            }
            catch(IllegalArgumentException e)
            {
               System.out.println("Programmierfehler: setter wirft Exception trotz vorhergehender Validierung");
            }
            
            break;
            
         case Form.INVALID:
            System.out.println("data ist keine Zahl >= 0");
            break;
            
         case Form.NOT_A_NUMBER:
            System.out.println("data ist keine Zahl");
            break;
            
         case Form.EMPTY:
            System.out.println("data ist leer");
            break;
            
         default:
            System.out.println("Programmierfehler: unbekannte Validierungsrückgabe");
      }      
   }
}

Das Integer.parseInt im Main stört mich irgendwie. Das mache ich schon in der Klasse Form. Ich mache es also doppelt.

Sollte validateData gleich den gültigen Wert (also den int-Wert) zurückgeben?