Uma limitação das macros desenvolvidas e demonstradas na seção anterior é que não é possível aninhar o tratamento de exceções ou escrever funções que tratem exceções e a disparem para um escopo externo. O problema pode ser resolvido fazendo com que o usuário da biblioteca possa interferir no nome adotado para as variáveis que são essenciais para os procedimentos responsáveis pelo tratamento das exceções.

Há várias formas de permitir que o usuário consiga interferir no nome das variáveis usadas pelos procedimentos de tratamento de exceções descrito nesse texto, aqui adota-se uma técnica simples, onde todas as macros definidas devem receber um argumento adicional que servirá de sufixo para o nome das variáveis utilizadas:


E para nomear os argumentos utilizados pelas funções que disparam as exceções, a macro THROW_NAMED_ARGS foi introduzida. Como consequências, a definição da macro THROW_ARGS pode ser simplificada. Dessa forma na assinatura da função, recomenda-se o uso de THROW_ARGS, e na sua implementação, o uso de THROW_NAMED_ARGS.


Com isso, podemos escrever códigos que aninham exceções como o do exemplo abaixo:


Esse código irá imprimir na tela:

"Erro: disparando exceção da função \"a\" de dentro de seu próprio bloco catch\n"

Se você leu o código com atenção, deve ter percebido que há um vazamento de memória. Na função a, uma chamada a função b é feita, então a função b aloca espaço para um ponteiro (que irá apontar para a string), então a função captura uma exceção e retorna do bloco CATCH (através da chamada a função longjmp) sem liberar o espaço alocado para o ponteiro (ele só seria liberado na linha de código onde ENDTRY se encontra).

Para resolver o problema, devemos introduzir uma nova macro, que libere os recursos alocados para o valor disparado:


Antes podíamos realizar saltos para fora de blocos TRY, agora podemos fazer o mesmo com blocos CATCH.