Exception-Hierarchie unter Java

Java nutzt, wie viele andere Sprachen, Exceptions zur Fehlersignalisierung und Fehlerbehandlung. Folgender Code würde hierbei dem Anschein nach alle Exceptions fangen:

try {
  // Do something wrong
} catch(Exception e) {
  // Gotta Catch 'Em All
}

An dieser Stelle trügt der Schein nicht. Allerdings werden nur einige Fehlerklassen gefangen, nämlich nur solche vom Typ Exception. Die Hierarchie der Fehlerklassen ist unter Java ein wenig differenzierter. In Java erbt jede Klasse implizit von der Klasse Object und so erbt auch die Klasse Throwable von dieser und implementiert das Interface Serializable.

Die Hierarchie der Klassen, welche für Fehlersignalisierung zuständig sind

Von der Klasse Throwable wiederum erben die Klassen Error und Exception. Fehler vom Typ Error stellen laut Definition immer Fehler innerhalb der JVM da, während Exceptions gewöhnliche Fehler des Programmes bzw. des Entwicklers sind. Sollen nun alle Fehlerklassen gefangen werden, so müsste der Quellcode wie folgt aussehen:

try {
  // Do something wrong
} catch(Throwable t) {
  // Gotta Catch 'Em All
}

Das Beispiel sollte nur als solches betrachtet werden, da es sich immer empfiehlt spezielle Fehler zu fangen und zu behandeln. Ein solch allgemeiner Fehlerhandler eignet sich nur für Spezialfälle wie z.B. das Logging nicht behandelter Fehler. Die Hierarchie verästelt sich anschließend noch weiter, so erben unterschiedlichste Klassen von der Klasse Error. Bei der Klasse Exception sieht dies ähnlich aus, allerdings existiert hier eine Besonderheit, die Klasse RuntimeException. Normalerweise muss eine Methode Exceptions, die sie wirft im Methodenkopf bekannt geben, wenn sie nicht in der Methode behandelt werden:

public static void example() throws Exception {
  throw new Exception();
}

Bei Klassen die von der Klasse RuntimeException erben muss diese Bekanntmachung im Methodenkopf nicht erfolgen. Sie werden trotzdem nach oben durchgereicht bis sie gefangen werden oder sich das Programm beendet, wenn die Behandlung der Exception nicht durchgeführt wurde.

jQuery Mobile und jQuery UI sind tot

Die bekannte JavaScript-Bibliothek jQuery, welche unter anderem zur Manipulation des DOMs genutzt wird, wird von zwei Bibliotheken flankiert, welche sich dem UI annehmen. Die Rede ist von jQuery Mobile und jQuery UI. Mithilfe dieser Bibliotheken ist es möglich Oberflächen für Webanwendungen zu entwickeln.

Eine mittels jQuery UI entwickelte Webapplikation

Während sich die Bibliotheken weiterhin sehr beliebt sind, was sich unter anderen in den Fragen auf Stack Overflow widerspiegelt, gibt es ein Problem mit den Projekten; sie sind praktisch tot. Der letzte Commit für jQuery UI ist vom Mai 2017 und auch die Entwicklung der letzten Jahre von jQuery Mobile ist sehr übersichtlich. Ansonsten sind viele andere Zeichen zu entdecken das die beiden Projekte tot sind.

Für neue Projekte in der Webentwicklung, sollte sich deshalb nach einem anderen Framework für die Erstellung von Weboberflächen umgesehen werden. Eine Alternative stellt unter anderem Framework 7 dar, welches von der Einfachheit der jQuery UI– und jQuery Mobile-Bibliotheken inspiriert ist.

Internationalisierung mittels JavaScript

Für mein neues Projekt Wryte war ich auf der Suche nach einer Möglichkeit die Anwendung zu lokalisieren. Das genutzte Framework 7 unterstützt leider keine Lokalisierung von Haus aus, so das diese nachgerüstet werden musste. Zum Tragen kam hierbei die JavaScript-Bibliothek i18next. Nach dem Download und der Einbindung der Bibliothek kann diese initialisiert werden:

i18next
  .use(window.i18nextBrowserLanguageDetector)
  .init({
    debug: false,
    resources: {
      en: {
        translation: {
          "about": "About"
        }
      },
      de: {
        translation: {
          "about": "Über"
        }
      }
    }
  });

In diesem Fall wird zusätzlich der i18nextBrowserLanguageDetector eingebunden, damit die Sprache des Nutzers automatisch erkannt wird. Anschließend kann die Übersetzung abgerufen werden:

$('#tab-author').html(i18next.t('author'));

Nach diesem Schema lässt sich anschließend die gesamte Anwendung übersetzen. Die offizielle Projektseite von i18next ist unter i18next.com zu finden. Die Quelltexte der einzelnen Projektbestandteile sind auf GitHub zu finden. Lizenziert ist i18next unter der MIT-Lizenz und damit freie Software.

NVDA

Screenreader, also Programme, welche den Bildschirminhalt vorlesen, existieren einige am Markt. Benötigt werden solche Programme unter anderem von blinden Menschen. Neben den proprietären Lösungen existiert auch eine Open-Source-Lösung mit dem Namen NVDA. NVDA ist für Windows verfügbar und kann als portable App betrieben werden. Ist dies der Fall, hinterlässt die Software nach ihrer Nutzung keinerlei Spuren auf dem Rechner.

Die Einstellungen von NVDA

Bezogen werden kann NVDA unter nvaccess.org. Lizenziert ist NVDA unter der GPL und damit freie Software. Der Quelltext ist auf GitHub zu finden.