Startseite

Java: Checked Exceptions werfen ohne throws-Klausel

Code, der potenziell checked Exceptions wirft, wird of innerhalb eines try-catch-Blocks aufgerufen. Es existieren zwei Möglichkeiten, die Exception weiter zu werfen:

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

Beide Möglichkeiten können unerwünscht sein. In diesem Artikel wird eine Technik beschrieben, die beides unnötig macht. Sie wird throw sneaky genannt. Sie ist als statische Methode implementiert:

@SuppressWarnings("unchecked")
public static <E extends Exception, R> R throwSneaky(Exception e)
  throws E {
  
  throw (E) e;
}
Java: Methode throwSneaky

Der Code macht sich zwei Dinge zunutze:

  1. Der Unterschied zwischen checked und unchecked Exceptions existiert nur zur Compilezeit.
  2. Die potenziell geworfene checked Exception wird mit Hilfe von Generics versteckt.

Dazu folgendes Anwendungsbeispiel:

public static void main(String[] args) {
  try {
    new FileInputStream("nonexistent");
  } catch (FileNotFoundException e) {
    // Checked exception can be thrown
    // without throws clause.
    throwSneaky(e);
  }
}
Java: Sneaky Throw Anwendungsbeispiel

Die beschriebene Technik ist durch einen Thread auf stackoverflow.com inspiriert. Sie spart einen aber nicht den try-catch-Block. Hier hilft die Annotation @SneakyThrows im Project Lombok.

Eclipse: Methodenargumente vertauschen mittels Regular Expressions

Kürzlich habe ich ein Projekt von JUnit nach TestNG migriert. Mit Hilfe des Ecplipse Plugins war das ein one-click Task. Jede assert-Methode wird duch das Pendant in der Klasse org.testng.AssertJUnit ersetzt. Dies ist aber nur eine Zwischenlösung. Das Ziel ist die Verwendung von org.testng.Assert. Dies birgt eine kleine Herausforderung. JUnit's assert-Methoden mit zwei Argumenten, z.B. assertEquals oder assertSame definieren die Reihenfolge expected, actual. TestNG definiert dies genau umgekehrt. Deswegen müssen die Argumente vertauscht werden.

Das Vertauschen wird erreicht mittels Find/Replace und Regular Expressions. Um bspw. in allen assertEquals-Methoden die Argumente zu vertauschen, führen Sie folgende fünf Schritte aus:

  1. Innerhalb der jeweiligen Testklasse den Find/Replace-Dialog aufrufen, entweder über den Meüeintrag Edit oder mit der Tastenkombination [Strg]-F.
  2. Den Haken bei Regular expressions setzen.
  3. assertEquals\(([^,]+),\s*([^)]+)\s*\) in das Textfeld Find eingeben.
  4. assertEquals(\2, \1) in das Textfeld Replace eingeben.
  5. Den Button Replace All klicken.

Eclipse: Find-Replace Dialog
Eclipse: Find-Replace Dialog

In der Expression im Textfeld Find werden zwei Capturing Groups verwendet. Sie werden erzeugt mit ([^,]+) und ([^)]+). Im Textfeld Replace werden sie in vertauschter Reihenfolge referenziert mit \2 und \1.

Buch: 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 Angreifern. Diese wollen sie zum Versand von Spam an Dritte missbrauchen oder 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 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 gut gegliedert. Einzelne Kapitel, die Themen behandeln, die man selbst nicht benötigt, können getrost ausgelassen werden. 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 sich alle Restrictions in der Sektion "smtpd_recipient_restrictions" befinden. Es fehlt der Hinweis, 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, 2008
Bewertung
4/5