Exceptions versus Status Code propagation
- Exceptions vs. status returns by Ned Batchelder
- or StackTrace: Why is it better to throw an exception rather than return an error code?
- or StackTrace 2: Exceptions or error codes
Java Exception Handling
- Best Practice by Thorben Janssen
Was ist gutes Error-Handling?
Gute Fehlerbehandlung bietet Übersicht, welche Fehlersituationen zu welcher Reaktion führen.
Mögliche Reaktionen bei Fehlern:
- SW gibt Exception weiter an caller
- SW erstellt Teilresultate, mit Fehler-Informationen
- …
In allen meinen vergangenen Projekten hat man mit Error-Codes (Strings) gearbeitet. Es ist dann immer recht schwierig von diesen Error-Code auf deren Verarbeitung zu schliessen.
Wäre es nicht besser, mit Exceptions zu arbeiten, statt mit Fehlercodes? Wäre es nicht besser, für alle Fehlersituationen, die eine bestimmte Reaktion hervorrufen (z.B. erstellen eines Teilresultats mit Fehlerinfo) dieselbe Exception zu werfen?
Wäre es nicht sinnvoll, wenn die Prozedur, die die Fehlerreaktion hervorrufen würde Teil der Exception wäre, bzw. die Exception das Interface implementieren würde?
Siehe auch: Exceptions versus Status Code propagation
Aufgaben eines guten Error-Handlings
Mitteilen:
- Was ist passiert
- Welche ursache hat welchen Impact –> Triage ermöglich. Wichtiges zuerst lösen.
- Wie kann es gelöst werden.
- Konstistenten Zustand im System zurück lassen. ROLLBACK.
Inhalt des Exception Objekt:
Typem von Exception Objekten:
- Environmen Exception (Unterteilbar in Service Exception (unterteilbar in ServiceUnavailableEx und ServiceResponseException) und Platform Exception)
Eine Platform Komponente oder ein Sevice war nicht verfügbar. - Data Validation Exception
Ein Feld hat keinen/falschen Wert
Felder:- Feld
- Key
- Value
- Breached Constraint
- Herkunft (wer hat das feld geliefert)
- Feld
- Allgemeine Exception Informationen: (Basisklasse. Data Validationn Exc und Environment Exc leiten davon ab)
- Was ging schief (ist bei Environment Exceptions schon inherent klar)
- Current Process (der nicht hat erfolgreich ausgeführt werden können)
- Info- oder Addendum-Meldungen: Mit (teilweise) demselben Mechanismus wie exceptions werden of jegliche art von Processing-Messages verarbeitet. Das hat zu folge, dass auch Infos (z.B. „77 items verarbeitet“) als „Exception“ prozessiert werden.
List mit einem einzigen Element erstellen
public static <T> List<T> singletonList(T o) {
return new SingletonList<>(o);
}
Hinzufuegen zu mapped Liste (:Map.computeIfAbsent)
Eine Liste innerhalb einer Map erweitern falls sie schon vorhanden ist oder sonst neu erstellen:
private Map<Object, List<Object>> addToMappedList1(Map<Object, List<Object>> mapOfLists, Object key, Object newValue){
if (mapOfLists.get(key) == null){
mapOfLists.put(key, new ArrayList<>());
}
mapOfLists.get(key).add(newValue);
return mapOfLists;
}
Eleganter:
private Map<Object, List<Object>> addToMappedList2(Map<Object, List<Object>> mapOfLists, Object key, Object newValue){
mapOfLists.computeIfAbsent(key, k -> new ArrayList<>()).add(newValue);
return mapOfLists;
}
Kategorien – Mapping
- Multi-Threading –> Concurrency –> Parrallel Processing
- Stream –allenfalls–> Lambda
Mittels Stream API Flache Liste von Liste von Listen erstellen
Beispiel:
List<List<Object>> list = ...
List<Object> flat =
list.stream()
.flatMap(List::stream)
.collect(Collectors.toList());(taken from)
Erklärung:
// List of Lists:
List<List<String>> listOfLists = new ArrayList<>();
listOfLists.add(Arrays.asList("Buenos Aires", "Córdoba", "La Plata"));
listOfLists.add(Arrays.asList("Bern", "Chur", "Luzern"));
List<String> result = listOfLists.stream().flatMap(list -> list.stream()).collect(Collectors.toList());
Signatur von flatMap(..):
<R> Stream<R> flatMap(Function<? super T, ? extends Stream<? extends R>> mapper);
T : Das Element mit dem der Stream parametrisiert ist, auf dem flatMap(..) aufgerufen wird.
Von flatMap verlanges Functional interface:
Function<? super T, ? extends Stream<? extends R>> :
interface Function<T, R> {
R apply(T t);
}
Das heisst bezüglich übergebener Funktion/Lambda-Expression:
Input von apply: Ist gleich dem Element-Parameter des Streams auf dem flatMap aufgerufen wird.
Output von apply: <? extends Stream<? extends R>>:
Ein Stream von irgendwas. –> Ich darf selbst bestimmen, was R dann wirklich ist. Dadurch, wie meine übergebene Funktion aktuell parametrisiert ist, wird R erst bestimmt.
Mittels Stream API Flache Liste von Map von Listen erstellen:
private List getAllAepfel(Map<UID, List<Apfel>> uidToApfelList) {
List xq = uidToApfelList.values().stream().flatMap(List::stream).collect(Collectors.toList());
}
Concurrency mit Spring – Scope beachten
Spring Scopes:
Aus MyKong:
5 types of bean scopes supported :
- singleton – Return a single bean instance per Spring IoC container
- prototype – Return a new bean instance each time when requested
- request – Return a single bean instance per HTTP request. *
- session – Return a single bean instance per HTTP session. *
- globalSession – Return a single bean instance per global HTTP session. *
In most cases, you may only deal with the Spring’s core scope – singleton and prototype, and the default scope is singleton.
P.S * means only valid in the context of a web-aware Spring ApplicationContext
Das heisst: Wenn das Bean mit Scope=“singleton“ (default) definiert ist, muss das Bean stateless sein.
Siehe auch: https://stackoverflow.com/questions/1745790/spring-singleton-session-scopes-and-concurrency
Referenzieren, statt kopieren
Oft meint man man arbeite auf einem Objekt, das nur einem selbst gehört. In Wirklichkeit wird aber andernorts genau dasselbe Objekt gehalten und verändert.