Fehler- und Ausnahmebedingungsbehandlung

In diesem Abschnitt wird hauptsächlich auf die Aspekte in Bezug auf die Fehler- und Ausnahmebedingungsbehandlung eingegangen, die bei der Entwicklung benutzerdefinierter Erweiterungen für WebSphere Message Broker in C berücksichtigt werden sollten.Wenn Sie benutzerdefinierte Erweiterungen in Java entwickeln, können Sie die Java-Standardmethoden für die Fehler- und Ausnahmebedingungsbehandlung verwenden. Wenn WebSphere Message Broker beispielsweise intern eine Ausnahmebedingung auslöst, wird eine Java-Ausnahmebedingung der Klasse MbException zur Verfügung gestellt.

Die richtige Behandlung von Fehlern und Ausnahmebedingungen ist wichtig für einen fehlerfreien Brokerbetrieb. Dies sollten Sie beachten und wissen, wann und wie die benutzerdefinierte Erweiterung Fehler und Ausnahmebedingungen behandeln muss.

Der Nachrichtenbroker generiert C++-Ausnahmebedingungen, um Fehlerbedingungen zu behandeln. Diese Ausnahmebedingungen werden in den relevanten Softwareschichten im Broker abgefangen und entsprechend behandelt. Allerdings können Programme, die in C geschrieben wurden, keine C++-Ausnahmebedingungen abfangen; alle ausgelösten Ausnahmebedingungen werden in benutzerdefiniertem Erweiterungscode, der in C erstellt wurde, ignoriert und in den höheren Schichten des Nachrichtenbrokers abgefangen.

Dienstprogrammfunktion verwenden die Rückgabewerte, um angeforderte Daten zurückzugeben, z. B. die Adresse oder interne Kennung eines Brokerobjekts. Hin und wieder weist der Rückgabewert darauf hin, dass ein Fehler aufgetreten ist. So wird beispielsweise ein Nullwert ((CCI_NULL_ADDR) zurückgegeben, wenn die Adresse oder die interne Kennung eines Brokerobjekts nicht abgerufen werden konnte. Darüber hinaus wird die Ursache einer Fehlerbedingung im Ausgabeparameter für den Rückkehrcode gespeichert, der gewöhnlich Teil des Funktionsprototyps aller Dienstprogrammfunktionen ist. Wenn die Dienstprogrammfunktion erfolgreich ausgeführt wurde und der Rückkehrcode (returnCode) ungleich Null ist, dann enthält returnCode den Wert 'CCI_SUCCESS'. Andernfalls wird einer der unten aufgeführten Rückkehrcodes zurückgegeben. Der Wert von returnCode kann immer als sicherer Hinweis dafür genommen werden, ob eine Dienstprogrammfunktion erfolgreich abgeschlossen wurde.

Wenn der Aufruf einer Dienstprogrammfunktion dazu führt, dass der Broker eine Ausnahmebedingung auslöst, wird dies von der benutzerdefinierten Erweiterung nur dann erkannt, wenn diese für den returnCode-Parameter für die betreffende Dienstprogrammfunktion einen Wert angegeben hat. Wurde für returnCode ein Nullwert angegeben, und es wird eine Ausnahmebedingung ausgelöst, so gilt Folgendes:

Dies bedeutet, dass eine benutzerdefinierte Erweiterung keine eigene Fehlerbehebung ausführen könnte. Wenn der returnCode-Parameter allerdings angegeben wurde und eine Ausnahmebedingung ausgelöst wird, dann wird 'CCI_EXCEPTION' als Rückkehrcode zurückgegeben. In diesem Fall können mit der Funktion cciGetLastExceptionData oder cciGetLastExceptionDataW Diagnoseinformationen zum vorliegenden Ausnahmetyp eingeholt werden. (Der Unterschied zwischen den beiden Funktionen ist, dass cciGetLastExceptionDataW eine CCI_EXCEPTION_WIDE_ST-Struktur zurückgibt, die Unicode-Trace-Text enthalten kann.) Die Daten werden in der CCI_EXCEPTION_ST- bzw. CCI_EXCEPTION_WIDE_ST-Struktur zurückgegeben.

Wenn keine Ressourcen freigegeben werden müssen, sollte das Argument 'returnCode' in der benutzerdefinierten Erweiterung nicht gesetzt werden. Wird dieses Argument nicht gesetzt, bleiben Ausnahmebedingungen in der benutzerdefinierten Erweiterung unbemerkt. Diese Ausnahmebedingungen können dann in den höheren Schichten des WebSphere Message Broker-Stacks vom Broker selbst behandelt werden.

Die Nachrichteneinfügungen können in den CCI_STRING_ST-Members der CCI_EXCEPTION_ST-Struktur zurückgegeben werden. Durch die CCI_STRING_ST-Struktur kann die benutzerdefinierte Erweiterung einen Puffer für den Empfang erforderlicher Einfügungen zur Verfügung stellen. Der Broker kopiert die Daten in diesen Puffer und gibt die Anzahl der ausgegebenen Bytes sowie die tatsächliche Länge der Daten zurück. Wenn der Puffer nicht ausreicht, werden keine Daten kopiert; der Puffer kann allerdings ggf. über das "dataLength"-Member vergrößert werden.

Beginn der ÄnderungDie benutzerdefinierte Erweiterung kann bei Bedarf eine eigene Fehlerbehebung durchführen, indem returnCode auf einen Wert ungleich Null gesetzt wird. Die Dienstprogrammfunktionsaufrufe kehren zur benutzerdefinierten Erweiterung zurück und übergeben ihren Status im returnCode. Alle Ausnahmebedingungen, die in einer Dienstprogrammfunktion auftreten, müssen an den Nachrichtenbroker übergeben werden, damit eine zusätzliche Fehlerbehebung durchgeführt werden kann, d. h., wenn in returnCode der Wert 'CCI_EXCEPTION' zurückgegeben wird. Rufen Sie zu diesem Zweck cciRethrowLastException auf, nachdem die benutzerdefinierte Erweiterung ihre eigene Fehlerbehandlung beendet hat. Der Aufruf von cciRethrowLastException veranlasst die C-Schnittstelle, die letzte Ausnahmebedingung erneut auszulösen, so dass diese von anderen Schichten im Nachrichtenbroker behandelt werden kann. Ähnlich wie bei dem C-Aufruf exit wird cciRethrowLastException in diesem Fall nicht zurückgegeben.Ende der Änderung

Wenn eine Ausnahmebedingung auftritt und von einer benutzerdefinierten Erweiterung abgefangen wird, darf die Erweiterung außer cciGetLastExceptionData,cciGetLastExceptionDataW oder cciRethrowLastException keine anderen Dienstprogrammfunktionen aufrufen. Jeder Versuch, eine andere Dienstprogrammfunktion aufzurufen, führt zu einem unvorhersehbaren Verhalten und kann unter Umständen nachteilige Auswirkungen auf die Brokerintegrität haben.

Wenn eine benutzerdefinierte Erweiterung einen schwerwiegenden Fehler feststellt, kann über cciThrowException oder cciThrowExceptionW eine Ausnahmebedingung erstellt werden, die dann vom Nachrichtenbroker auf korrekte Weise behandelt wird. Durch die Generierung einer solchen Ausnahmebedingung werden die zur Verfügung gestellten Daten in das Systemprotokoll (syslog oder Ereignisanzeige) geschrieben, falls die Ausnahmebedingung nicht behandelt wird. Diese Daten werden auch in das Traceprotokoll des Brokers geschrieben, sofern die Tracefunktion aktiviert wurde.

Ausnahmebedingungstypen und Brokerverhalten

Der Broker erstellt eine Reihe von Ausnahmebedingungen, die an eine benutzerdefinierte Erweiterung übergeben werden kann. Diese Ausnahmebedingungen können auch von einer benutzerdefinierten Erweiterung beim Auftreten einer Fehlerbedingung generiert werden. Bei den Ausnahmeklassen handelt es sich um folgende:

Fatal (Schwer wiegende Ausnahme)
Schwer wiegende Ausnahmebedingungen werden beim Auftreten einer Bedingung generiert, die eine sichere Ausführung des Brokerprozesses verhindert oder bei der der Prozess entsprechend den Brokerrichtlinien beendet wird. Eine schwer wiegende Ausnahmebedingung wird beispielsweise ausgelöst, wenn eine kritische Systemressource nicht angefordert werden kann oder wenn intern ein schwerer Softwarefehler abgefangen wird. Der Brokerprozess wird nach dem Auslösen einer schwer wiegenden Ausnahmebedingung beendet.
Recoverable (Behebbare Ausnahme)
Diese Ausnahmebedingungen werden bei Fehlern generiert, die zwar nicht unbedingt schwer wiegend sind, bei denen der aktuelle Nachrichtenfluss aber trotzdem beendet werden muss. Ein Beispiel für eine behebbare Ausnahmebedingung sind ungültige Daten in einer Nachricht oder wenn eine Nachricht nicht in einen Sendeknoten geschrieben werden kann. Beim Auslösen einer behebbaren Ausnahmebedingung wird die Verarbeitung der aktuellen Nachricht in diesem Thread abgebrochen, der Thread setzt aber die Ausführung im Empfangsknoten wieder fort.
Configuration (Konfigurationsausnahme)
Konfigurationsausnahmebedingungen werden generiert, wenn eine Konfigurationsanforderung fehlschlägt. Eine solche Bedingung kann beispielsweise durch einen Formatfehler in der Konfigurationsanforderung verursacht werden oder durch einen Datenfehler. Beim Auslösen einer Konfigurationsausnahmebedingung wird die Anforderung zurückgewiesen und als Antwort eine Fehlernachricht zurückgegeben.
Parser (Parserausnahme)
Diese Ausnahmebedingungen werden von Nachrichtenparsern bei Fehlern generiert, die eine Snytaxanalyse des Nachrichteninhalts oder die Erstellung eines Bitstroms verhindern. Eine Parserausnahmebedingung wird wie eine vom Broker ausgelöste behebbare Ausnahmebedingung behandelt.
Conversion (Konvertierungsausnahme)
Konvertierungsausnahmebedingungen werden von den Brokerfunktionen für die Zeichenkonvertierung generiert, wenn bei der Konvertierung in einen anderen Datentyp ungültige Daten festgestellt werden. Eine Konvertierungsausnahmebedingung wird wie eine vom Broker ausgelöste behebbare Ausnahmebedingung behandelt.
User (Benutzerausnahme)
Diese Ausnahmebedingungen werden generiert, wenn ein Ausnahmeknoten eine benutzerdefinierte Ausnahme auslöst.
Database (Datenbankausnahmen)
Datenbankausnahmen werden generiert, wenn ein Datenbankmanagementsystem während des Brokerbetriebs einen Fehler meldet. Eine Datenbankausnahmebedingung wird wie eine vom Broker ausgelöste behebbare Ausnahmebedingung behandelt.
Zugehörige Konzepte
Fluss-Debugger
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Rückmeldung
Copyright IBM Corporation 1999, 2006 Letzte Aktualisierung: 23. Aug. 2006
as01430_