Start

Java: Checked Exceptions werfen ohne throws Klausel

Code, der potenziell checked Exceptions wirft, wird oft innerhalb eines try-catch-Blocks verarbeitet. Es gibt zwei Möglichkeiten, die dort gefangene Exception an den Aufrufer weiter zu leiten:

  1. Die checked Exception in eine Instanz von RuntimeException wrappen
  2. Eine throws-Klausel deklarieren

Beide Möglichkeiten sind ggf. unerwünscht. In diesem Artikel wird ein Verfahren vorgestellt, checked Exceptions zu werfen, unter Umgehung beider Möglichkeiten. Das Verfahren wird als throw sneaky bezeichnet. Es ist als statische Methode implementiert:

@SuppressWarnings("unchecked")
public static <T extends Throwable> T throwSneaky(Throwable t)
  throws T {
  throw (T) t;
}
Throw Sneaky

Der Code macht sich zwei Dinge zu Nutze:

  1. Der Unterschied zwischen checked und unchecked Exceptions ist etwas, dass nur zur Compilezeit existiert.
  2. Die Tatsache, dass eine checked Exception geworfen wird, wird vor dem Compiler durch das generische Methodenargument <T extends Throwable> verborgen.

Folgender Code gibt ein Anwdendungsbeispiel:

// keine throws klausel
public static void main(String[] args) {
  try {
    new FileInputStream("nonexistent");
  } catch (FileNotFoundException e) {
    // FileNotFoundException kann ohne
    // throws Klausel geworfen werden.
    throw Sneaker.throwSneaky(e);
  }
}
Anwdendungsbeispiel

Das beschriebene Verfahren ist inspiriert durch eine Diskussion auf stackoverflow.com. Es spart einen aber nicht den try-catch-Block in Echtwelt-Code. Hier hilft Project Lombok mit der Annotation @SneakyThrows

Eclipse: Parameterreihenfolge vertauschen mit Hilfe von Regular Expressions

Ich habe kürzlich ein Projekt von JUnit nach TestNG migriert. Mit dem entsprechenden Plugin von Ecplipse geht das meiste auf Knopfdruck. Alle assert-Methoden werden umgewandelt in die gleichnamigen Methoden der Klasse org.testng.AssertJUnit. Ich hielt das aber für eine Zwischenlösung und wollte die Methoden der Klasse org.testng.Assert nutzen. Hier gibt es eine kleine Herausforderung. Bei assert-Methoden, die zwei Parameter erwarten z.B. assertEquals oder assertSame erwartet JUnit die Parameter in der Reihenfolge expected, actual. Bei TestNG ist die Parameterreihenfolge genau umgekehrt. Die Reihenfolge muss also vertauscht werden.

Beim Vertauschen der Parameter kommt einem das Find/Replace mit Regular Expressions zur Hilfe. Um bspw. alle assertEquals-Methoden zu finden und darin die Parameter zu vertauschen, muss man folgendes machen:

  1. In der entsprechenden Testklasse den Find/Replace-Dialog aufrufen, entweder im Menü über Edit oder mit [Strg]-F.
  2. Den Haken bei Regular expressions setzen
  3. Im Feld Find folgenden Text eingeben: assertEquals\(([^,]+),\s*([^)]+)\s*\)
  4. Im Feld Replace with folgenden Text eingeben: assertEquals(\2, \1)
  5. Den Button Replace All klicken.

Der Trick hierbei ist, dass man mit Regular Expressions nicht nur nach Matches suchen kann, sondern über sog. Capturing Groups auch auf diese referenzieren kann. Die Capturing Groups werden in dem o.a. Beispiel mit ([^,]+) bzw. ([^)]+) erzeugt und werden, nummeriert nach ihrem Auftreten, mit \1 bzw. \2 referenziert.

Postfix Einrichtung Betrieb und Wartung

Postfix ist einer der am weitest verbeiteten Mail Transfer Agents (MTA). Bei den meisten Linux Distributionen ist er als installierbares Paket verfügbar. Damit ist ein (meist sogar einigermaßen sicher konfiguriertes) Postifx schnell ans Laufen gebracht. Aber MTAs sind das Ziel von Spammern. Diese wollen sie erstens zum Versand von Spam an Dritte missbrauchen und zweitens Spam an die vom MTA verwalteten Postfächer senden. Um das zu verhindern, ist peinlichst auf eine sichere Konfiguration zu achten. Dafür ist einiges an Wissen erforderlich, welches die Autoren Ralf Hildebrandt und Patrick Ben Koetter in ihrem Buch vermitteln wollen.

Die Autoren arbeiten sich in dem in vier Teile untergliederten Buch von den Grundlagen über die sichere Konfiguration bis hin zum Tuning und der Umsetzung von Spezialanforderungen vor. Das Buch ist so gut gegliedert, dass einzelne Kapitel, die Themen behandeln, die man selbst nicht benötigt, getrost ausgelassen werden können. Das Verständnis der restslichen Inhalte wird dadurch nicht behindert.

Die Kapitel über eine sichere Grundkonfiguration, das Filtern von Emails mittels sog. Restrictions, SMTP-Authentifizierung und Tuningmaßnahmen sind besonders positiv hervorzuheben. Das Thema Verschlüsselung der Authentifizierung mittels Digest-Verfahren wird naturgemäß eher knapp behandelt. Die Autoren konzentrieren sich mehr auf die Verschlüsselung der Verbindung mittels TLS. An dem Kapitel über die Restrictions ist zu bemängeln, dass die Autoren alle Restrictions in die Sektion "smtpd_recipient_restrictions" schreiben, ohne darauf hinzuweisen, dass Postfix hier detailliertere Möglichkeiten bietet.

Das Buch stattet Postfix Administrierende mit dem nötigen Wissen aus, um einen sicheren Mailserver zu betreiben. Wo es Lücken aufweist, hilft die Online-Dokumentation von Postfix weiter. Diese wird nach der Lektüre des Buches wesentlich verständlicher. Es ist uneingeschränkt zum Kauf zu empfehlen. Das investierte Geld und die Zeit lohnen sich auf jeden Fall.

Autoren
Ralf Hildebrandt, Patrick Ben Koetter
ISBN
978-3-89864-518-8
Verlag
dpunkt.verlag GmbH, Heidelberg,
Bewertung
4/5