Fehlerhandling

Ein Qualitätsmerkmal einer Software ist die Unterstützung des Benutzers im Fehlerfall. Fehlermeldungen, die dem Benutzer angezeigt werden, sollten in einer für ihn verständlichen Sprache verfasst sein. Dennoch müssen alle technischen Details festgehalten werden, die für eine weitere Bearbeitung notwendig sind. Ich möchte den Absatz "Fehlerhandling" in zwei Bereiche gliedern:

• Darstellung von Fehlern
• Logging

Die Darstellung von Fehlern ist technisch gesehen unproblematisch. Mit dem ErrorDialog bietet JFace ein entsprechendes Widget. Hier können sowohl eine lesbare Fehlermeldung im Dialog als auch technische Details im Detailbereich dargestellt werden. Interessant ist eher die Frage, woher die dargestellten Informationen stammen. Fehlersituationen innerhalb des Clients sind dabei relativ gut zu kontrollieren, da an entsprechenden Stellen die passenden Fehlermeldungen generiert werden können. Anders ist es bei der Kommunikation zum Server. Hier können serverseitig beispielsweise technische Ausnahmen wie SQLExceptions oder JMSExceptions auftreten, die zunächst übersetzt werden müssen. Es empfiehlt sich, für die Fehlerbenachrichtigung eine eigene Exception-Klasse für Serviceaufrufe zu verwenden. Die Serverseite konvertiert dabei sämtliche Fehlermeldungen in die entsprechende Exception-Klasse und entkoppelt sie von eventuell abhängigen Bibliotheken. Dieser Punkt ist insofern wichtig, da sonst Exceptions von Bibliotheken, die clientseitig nicht vorhanden sind, nicht dargestellt werden können bzw. zu ClassNotFoundExceptions bei der Deserialisierung der Response führen. Dieser Vorgang kann serverseitig beispielsweise durch den Spring-Interceptor-Mechanismus mit einem Advice umgesetzt werden, der für Methodenaufrufe deklariert wird.

1. <bean class="org.springframework.aop.framework.ProxyFactoryBean" id="fooRemoteService">
2. <property name="proxyInterfaces" value="com.demo.IFooRemoteService"/>
3. <property name="target" ref="fooRemoteServiceTarget"/>
4. <property name="interceptorNames">
5. <list>
6. <value>securityAdvice</value>
7. <value>exceptionAdvice</value>
8. </list>
9. </property>
10. </bean>
11. <bean class="com.foo.ExceptionAdvice" id="exceptionAdvice"/>

Der Aspekt kann dann die Exception-Klasse für den Serviceaufruf mit zusätzlichen, zur jeweiligen Fehlersituation vorhandenen Informationen anreichern.

1. public class ServiceExceptionAdvice implements ThrowsAdvice {
2. public void afterThrowing(Throwable throwable) throws Throwable {
3. if (throwable instanceof ServiceException) {
4. throw throwable;
5. }
6. // zusätzliche Informationen können hier hinzugefügt werden
7. throw new ServiceException(throwable);
8. }
9. }

Logging

Zum Abschluss möchte ich im Rahmen der Fehlerbehandlung noch auf das Thema "Logging" eingehen. Auch hier bietet die Eclipse-Plattform eine integrierte Lösung. Vom Activator eines Plug-ins lässt sich mit der Methode getLog() auf das ILog des Plug-ins zugreifen. Das ILog hat eine log(IStatus)-Methode, mit der in die Eclipse-Logdatei geschrieben wird. Das IStatus-Objekt beinhaltet dabei sowohl den Text als auch das Log-Level. Die Verwendung der Methode ist so etwas sperrig, da das Erzeugen des IStatus-Objekts sehr umständlich ist. Einfacher ist eine Fassade, die die Erzeugung kapselt. Das Interface der Fassade ähnelt dabei dem von bekannten Logging-Frameworks wie Log4J.

1. public interface IPluginLogger {
2. void info(String message, Throwable throwable);
3. void info(String message);
4. void error(String message);
5. void error(Throwable throwable);
6. void error(String message, Throwable throwable);
7. }

Die Implementierung delegiert dann die einzelnen Log-Methoden an eine einzige Methode, die das benötigte IStatus-Objekt erzeugt.

1. public final class PluginLogger implements IPluginLogger {
2. private Plugin runtimePlugin;
3. ...
4. public final void info(String message, Throwable throwable) {
5. log(IStatus.INFO, IStatus.OK, message, throwable);
6. }
7. ...
8. private final void log(int severity, int code, String message, Throwable exception) {
9. String symbolicName = runtimePlugin.getBundle().getSymbolicName();
10. IStatus status = new Status(severity, symbolicName, code, message, exception);
11. runtimePlugin.getLog().log(status);
12. }
13. }

So lässt sich das ILog wie ein gewöhnliches Logging-Interface verwenden. Was aber, wenn man serverseitig und clientseitig das gleiche Logging-Framework einsetzen möchte? Mithilfe eines ILogListener, der bei der Platform angemeldet werden kann, können sämtliche Logs des ILogs direkt an das Logging-Framework delegiert werden.

1. /**
2. * {@link ILogListener} that transfers the <i>Eclipse Log</i> to the
3. * corresponding <i>Log4J Log</i>.
4. public class LogTransfer implements ILogListener {
5. /** The Log4J logger. */
6. private Logger logger = Logger.getLogger(LogTransfer.class);
7. /** {@inheritDoc} */
8. public void logging(IStatus status, String plugin) {
9. String message = "[" + plugin + "] " + status.getMessage();
10. Throwable exception = status.getException();
11. switch (status.getSeverity()) {
12. case IStatus.CANCEL:
13. logger.error(message, exception);
14. break;
15. case IStatus.ERROR:
16. logger.error(message, exception);
17. break;
18. case IStatus.INFO:
19. logger.info(message, exception);
20. break;
21. case IStatus.OK:
22. logger.info(message, exception);
23. break;
24. case IStatus.WARNING:
25. logger.warn(message, exception);
26. break;
27. default:
28. logger.info(message, exception);
29. break;
30. }
31. }
32. }

Ob das Logging-Framework direkt oder die zuvor beschriebene Fassade verwendet wird, bleibt dann Geschmackssache. Jedenfalls ist sichergestellt, dass sämtliche Logs, auch die Logs der Eclipse-Plattform, ihren Weg ins Logging-Framework finden. Typischerweise wird als externes Logging-Framework Log4J genutzt. Die Verwendung stellt im OSGi-Kontext allerdings zunächst ein kleines Problem dar. Die Log4J-Bibliothek sollte als eigenes Bundle eingebunden werden. Für die Konfiguration ist allerdings eine Konfigurationsdatei notwendig. Um Log4J diese Konfigurationsdatei im Klassenpfad zugänglich zu machen, kann leicht ein Fragment verwendet werden, das als Host das Log4J Bundle definiert.

In einer verteilten Anwendung ist das Logging im Produktivbetrieb ein wichtiges Instrument zur Identifizierung von Fehlern. Im Fehlerfall stehen die gewünschten Informationen jedoch in der Log-Datei der jeweiligen Installationen. Der Zugriff gestaltet sich teilweise schwierig und umständlich. Wünschenswert ist dann ein so genanntes End-to-End-Logging, die Log-Statements werden dabei zusätzlich an den Server transferiert. Das bedeutet selbstverständlich einen erheblichen zusätzlichen Datenverkehr, der sich allerdings über das Log-Level steuern lässt. Der Transfer sollte dabei auch "nur" ein sekundäres Log darstellen, also die Log-Datei des Clients nicht ersetzen. Zusätzlich sollte der Transfer nebenläufig geschehen und die Clientfunktionen nicht behindern.

Links & Literatur

1. Enterprise Eclipse RCP, Teil 2: Remoting und Caching
2. Equinox & JAAS
3. Spring Security
4. Equinox Secure Storage
5. Equinox Security Project
6. Eclipse Capabilities
7. Kimberley Horne, Contexts and Capabilities
8. Eclipse Commands und Handler
9. Eclipse RCP im Unternehmenseinsatz, Stefan Reichert, dpunkt.verlag, August 2009