Questo argomento riguarda questioni correlate alla gestione di errori ed eccezioni che è necessario considerare quando si sviluppano estensioni definite dall'utente per WebSphere Message Broker nel linguaggio di programmazione C. Se si stanno sviluppando estensioni definite dall'utente utilizzando il linguaggio di programmazione Java, è possibile utilizzare metodi di gestione errori ed eccezioni Java standard. Se, ad esempio, WebSphere Message Broker genera internamente un'eccezione, viene resa disponibile un'eccezione Java di classe MbException.
Una corretta gestione degli errori e delle eccezioni è importante per un corretto funzionamento del broker. È necessario essere consapevoli e comprendere come e quando l'estensione definita dall'utente deve gestire errori ed eccezioni.
Il broker dei messaggi genera eccezioni C++ per la gestione di condizioni di errore. Tali eccezioni vengono rilevate nei relativi livelli di software nel broker e gestite di conseguenza. Tuttavia, i programmi scritti in C non possono acquisire le eccezioni C++, e le eventuali eccezioni generate ignorano, per impostazione predefinita, il codice dell'estensione definita dall'utente in C e verranno acquisite ad un livello superiore del broker dei messaggi.
Le funzioni di utilità, per convenzione, utilizzano normalmente il valore di restituzione per passare i dati richiesti; ad esempio, l'indirizzo o l'handle di un oggetto broker. Il valore di restituzione indica talvolta che si è verificato un malfunzionamento. Ad esempio, se non è stato possibile richiamare l'indirizzo o l'handle di un oggetto broker, viene restituito zero (CCI_NULL_ADDR). Inoltre, il motivo di una condizione di errore è memorizzato nel parametro di output del codice di ritorno, che, per convenzione, fa parte del prototipo di funzione di tutte le funzioni di utilità. Se la funzione di utilità è stata completata con esito positivo e returnCode non era null, returnCode conterrà CCI_SUCCESS. Altrimenti, conterrà uno dei codici di ritorno descritti di seguito. Il valore di returnCode può sempre essere verificato con sicurezza per determinare se una funzione di utilità ha avuto esito positivo.
Ciò significa che un'estensione definita dall'utente non sarà in grado di eseguire alcuno dei propri ripristini di errore. Se, tuttavia, è specificato il parametro returnCode e si verifica un'eccezione, viene restituito il codice di ritorno CCI_EXCEPTION. In tale caso, per ottenere informazioni diagnostiche sul tipo di eccezione che si è verificata, è possibile utilizzare cciGetLastExceptionData o cciGetLastExceptionDataW (la differenza consiste nel fatto che cciGetLastExceptionDataW restituisce un CCI_EXCEPTION_WIDE_ST che può contenere un testo di traccia Unicode). I dati vengono restituiti nella struttura CCI_EXCEPTION_ST o CCI_EXCEPTION_WIDE_ST.
Se non ci sono risorse da rilasciare, si consiglia di evitare l'impostazione dell'argomento returnCode nell'estensione definita dall'utente. Se questo argomento non viene impostato, le eccezioni possono ignorare le estensioni definite dall'utente. Tali eccezioni possono essere gestite fino allo stack WebSphere Message Broker dal broker.
Inserimenti di messaggi possono essere restituiti nei membri CCI_STRING_ST della struttura CCI_EXCEPTION_ST. CCI_STRING_ST consente all'estensione definita dall'utente di fornire un buffer per ricevere eventuali inserimenti richiesti. Il broker copia i dati nel buffer e restituisce il numero di byte di output e la lunghezza attuale dei dati. Se il buffer non è sufficientemente grande, non viene copiato alcun dato e il membro "dataLength" può essere utilizzato per aumentare la dimensione del buffer, se necessario.
Se necessario, l'estensione definita dall'utente può eseguire il ripristino dei suoi stessi errori, impostando un valore diverso da zero per returnCode.
La funzione di utilità richiama il ritorno all'estensione definita dall'utente e fa passare il loro stato attraverso returnCode. Tutte le eccezioni che si verificano in ogni funzione di utilità devono essere trasmesse al broker del messaggio per un ulteriore ripristino di errori, ossia, quando CCI_EXCEPTION viene restituito in returnCode.
Questo è possibile invocando cciRethrowLastException dopo che l'estensione definita dall'utente ha terminato la sua stessa elaborazione degli errori. Il richiamo di cciRethrowLastException comporta per l'interfaccia C la rigenerazione dell'ultima eccezione così che questa possa essere gestita da altri livelli nel broker del messaggio. Da notare che, similmente a un richiamo exit di C, in questo caso cciRethrowLastException non viene restituito.
Se si verifica un'eccezione e viene rilevata da un'estensione definita dall'utente, l'estensione non deve richiamare alcuna funzione di utilità ad eccezione di cciGetLastExceptionData, cciGetLastExceptionDataW o cciRethrowLastException. Nel tentativo di richiamare altre funzioni di utilità potrebbe verificarsi un funzionamento imprevedibile che può compromettere l'integrità del broker.
Se un'estensione definita dall'utente rileva un errore grave, è possibile utilizzare cciThrowException o cciThrowExceptionW per generare un'eccezione che viene elaborata dal broker dei messaggi nel modo corretto. La creazione di tale eccezione fa sì che le informazioni fornite vengano scritte sul log di sistema (syslog o Eventviewer) se l'eccezione non è gestita. Tali informazioni vengono scritte anche sulla traccia del broker se la traccia è attiva.
Il broker crea una serie di eccezioni che possono essere passate a un'estensione definita dall'utente. Tali eccezioni possono essere create anche da un'estensione definita dall'utente quando viene rilevata una condizione di errore. Le classi di eccezioni sono: