dies ist die Entscheidung, die dir als Programmierer gottähnliche Macht verleiht
beides ist denkbar und kann z.B. von der Verwendung, von der Aufgabe der Klasse abhängen,
eine allgemeine Collection oder eine Map, wie aus Standard-Java bekannt, würde einfach null zurückgeben, weil das tausendfach aufgerufen wird,
die Aufrufer rechnen mit einem solchen Rückgabewert und prüfen auf == null
je komplizierter die Klasse, je seltener und fachspezifischer die Aufrufe, desto eher kommt eine Exception in Frage,
z.B. wenn die Klasse eine User-Verwaltung ist und der Aufrufer nur die Login-Klasse sein soll die nach dem User zu einer Id/ zu einem Namen fragt,
selbst dann ist noch Rückgabewert null möglich, aber auch schon viel eher eine Exception
eine gute Regel ist weiterhin: kann der Aufrufer etwas mit dem Rückgabewert null anfangen?
kann er bei null direkt anders reagieren (etwa indem er ein fehlendes Objekt erstellt und in der Liste ergänzt, spricht für null)
oder ist es wahrscheinlicher, dass auch der Aufrufer dann seine Arbeit abbrechen muss (spricht für Exception)
ein etwas konstruiertes Beispiel für Exception:
die Liste enthält Wörterbücher für verschiedenen Sprachen,
an 20 Stellen im Programm wird über einen String 'sprachenname' ein Wörterbuch abgefragt und darin etwas nachgeschlagen,
bei einem unbekannten 'sprachenname' könnte der Rückgabewert null unpraktisch sein,
jeder der 20 aufrufenden Stellen kann sich nun eh nicht auf die Schnelle ein neues Wörterbuch ausdenken, müsste seine Arbeit abbrechen, vielleicht selber eine Exception werden mit Code
if (woerterbuch == null) {
throw new RuntimeException("unbekannte Sprache, hier gehts nicht weiter");
}
die dann ganz zentral in der Programmsteuerung behandelt wird,
in einem solchen Fall sollte ruhig die spezielle Wörterbuch-Liste die Aufgabe des Exception-Werfens übernehmen,
da muss das nur EINMAL geschehen, nicht 20x
