×
Namespaces

Variants
Actions
(Difference between revisions)

Abandonos (Leaves)

From Nokia Developer Wiki
Jump to: navigation, search
cabezonxdg (Talk | contribs)
cabezonxdg (Talk | contribs)
m (Adição da seção de TRAP)
Line 5: Line 5:
 
== TRAP Harness ==
 
== TRAP Harness ==
  
Para contornar a falta do sistema de exceção padrão foi desenvolvida a função TRAP e TRAPD que podem ser consideradas como alternativas ao Try/Catch. Ao ocorrer um abandono , este será propagado até que seja capturado por um TRAP. Caso não seja implementado pelo programador ele será capturado pelo TRAP do FrameWork e o SO irá tomar as precauções necessárias (Exibir uma dialog com o erro por exemplo)<br>
+
Para contornar a falta do sistema de exceção padrão foram desenvolvidas as funções TRAP e TRAPD que podem ser consideradas como alternativas ao Try/Catch (apesar de sua implementação interna no Symbian v9.0 ser feita utilizando Try/Catch). Na ocorrência de um abandono , ele será propagado até que seja capturado por uma TRAP. Caso a TRAP não seja implementada pelo programador o abandono será capturado pelo TRAP do FrameWork e o SO irá tomar as precauções necessárias (exibir uma dialog com o motivo do abandono por exemplo). No entando em algumas ocasiões o programador necessita gerenciar de forma particular um abandono e então fazemos o uso da função TRAP.<br>
 +
 
 +
Trap é uma função inline definida no cabeçalho e32cmn.h e pode ser definida como:
 +
 
 +
 
 +
 
 +
TRAP(_r, _s);
 +
 
 +
Esta função executa um conjunto de instruções C++ e retorna um inteiro com o valor do abandono (caso tenha ocorrido).
 +
 
 +
 
 +
 
 +
Onde:
 +
 
 +
 
 +
 
 +
_r = O código de abandono gerado pelas funções é salvo neste inteiro. Este inteiro precisa ser declarado antes de usar a TRAP.<br>
 +
 
 +
_s = Conjunto de instruções C++ que serão colocadas "a prova" utilizando a TRAP. Caso estas abandonem o valor é passado para _r.
 +
 
 +
Uma alternativa à TRAP é o TRAPD, utilizado apenas por conveniência onde o inteiro que recebe o código de abandono não precisa ser declaro explicitamente.
 +
 
 +
 
 +
 
 +
Exemplos de uso do TRAP:
 +
 
 +
<code cpp="cpp">TInt err;<br>TRAP(err, FuncaoQuePodeAbandonarL());<br>if( err == KErrNone ) // não ocorreu abandono<br>{<br> // faz algo<br>}<br>else // Ocorreu abandono<br>{<br> // faz algo <br>}</code>
 +
 
 +
Exemplo com TRAPD:
 +
 
 +
<code cpp="cpp">TRAPD(err, FuncaoQuePodeAbandonarL());<br>if( err == KErrorNone )<br>{<br> // faz algo<br>}<br>else<br>{<br> // faz algo<br>}</code>
 +
 
 +
'''Nota:''' A utilização de TRAPS pelo programa aumenta significamente o tamanho do código final da aplicação e causa um certo overhead, então deve ser utilizado com cautela.
  
 
== Pilha de limpeza ==
 
== Pilha de limpeza ==
Line 21: Line 53:
  
  
<br> <br> É feita a alocação dinâmica de um objeto do tipo CCarro e então este objeto chama o método DirigirL. Este método pode lançar uma exceção - ''Métodos que possam lançar exceção terminam com L'' - , caso uma exceção ocorra todas as variáveis automáticas do método CarregarAlgoL serão removidas incluindo neste caso o ponteiro fiat. Isto acontecendo perderemos a referência para a memória que fiat aponta - ''quando ocorre uma exceção não há garantia que o destrutor da classe será chamado ou que os códigos seguintes serão executados''-&nbsp; no exemplo, o comando delete nunca será executado. O resultado seria um vazamento de memória. Pode parecer que alguns bytes não representam muita coisa, mas para um sistema com recursos limitados e que não faz re-boot frequentemente isto pode ocasionar sérios problemas.<br>
+
<br> <br> <br> É feita a alocação dinâmica de um objeto do tipo CCarro e então este objeto chama o método DirigirL. Este método pode lançar uma exceção - ''Métodos que possam lançar exceção terminam com L'' - , caso uma exceção ocorra todas as variáveis automáticas do método CarregarAlgoL serão removidas incluindo neste caso o ponteiro fiat. Isto acontecendo perderemos a referência para a memória que fiat aponta - ''quando ocorre uma exceção não há garantia que o destrutor da classe será chamado ou que os códigos seguintes serão executados''-&nbsp; no exemplo, o comando delete nunca será executado. O resultado seria um vazamento de memória. Pode parecer que alguns bytes não representam muita coisa, mas para um sistema com recursos limitados e que não faz re-boot frequentemente isto pode ocasionar sérios problemas.<br>
  
 
Para resolver problemas como este foi desenvolvido o mecanismo de limpeza da pilha ( CleanupStack ). Considere o seguinte código:<br>
 
Para resolver problemas como este foi desenvolvido o mecanismo de limpeza da pilha ( CleanupStack ). Considere o seguinte código:<br>
  
 
<br>
 
<br>
<code cpp="cpp">void CMinhaClasse::CarregarAlgoL()<br>{<br> CCarro* fiat = new (ELeave) CCarro();<br> CleanupStack::PushL( fiat );<br> fiat->DirigirL();<br> CleanupStack::PopAndDestroy();<br>}</code>  
+
<code cpp="cpp">void CMinhaClasse::CarregarAlgoL()
 +
{
 +
        CCarro* fiat = new (ELeave) CCarro();
 +
        CleanupStack::PushL( fiat );
 +
        fiat->DirigirL();
 +
        CleanupStack::PopAndDestroy();
 +
}</code>  
 
<br>Caso não tenha notado, foram adicionadas duas linhas de código que representam chamadas à métodos de CleanupStack. Neste código, caso DirigirL abandone não perderemos a referência a memória que fiat aponta. Seu uso é bastante simples, você adiciona ponteiros automáticos à pilha e na ocorrência de um abandono será chamado o destrutor do objeto que este ponteiro aponta e então sua memória será liberada através do operador User::Free.
 
<br>Caso não tenha notado, foram adicionadas duas linhas de código que representam chamadas à métodos de CleanupStack. Neste código, caso DirigirL abandone não perderemos a referência a memória que fiat aponta. Seu uso é bastante simples, você adiciona ponteiros automáticos à pilha e na ocorrência de um abandono será chamado o destrutor do objeto que este ponteiro aponta e então sua memória será liberada através do operador User::Free.
  
  
 +
 +
<br>
  
 
<br>
 
<br>
Line 72: Line 112:
  
  
<br> <br> <br>
+
<br> <br> <br> <br>
  
 
== Leitura complementar ==
 
== Leitura complementar ==

Revision as of 05:49, 20 December 2007

Abandonos (Leaves) são utilizados ao invés do sistema tradicional de exceções do C++, a principal razão disso é pelo fato dos abandonos serem mais leves, necessitarem de menos linhas de códigos e também por não serem suportados pelo compilador GNU na época em que Symbian OS foi desenvolvido. Abandonos podem ocorrer como resultado de uma condição de erro ou de um evento anormal, como falta de memória ou de espaço em disco (ou falta de espaço no cartão de memória flash) para completar uma operação. O abandono propaga o erro a um local no código onde ele pode ser gerenciado, chamado TRAP harness.


Contents

TRAP Harness

Para contornar a falta do sistema de exceção padrão foram desenvolvidas as funções TRAP e TRAPD que podem ser consideradas como alternativas ao Try/Catch (apesar de sua implementação interna no Symbian v9.0 ser feita utilizando Try/Catch). Na ocorrência de um abandono , ele será propagado até que seja capturado por uma TRAP. Caso a TRAP não seja implementada pelo programador o abandono será capturado pelo TRAP do FrameWork e o SO irá tomar as precauções necessárias (exibir uma dialog com o motivo do abandono por exemplo). No entando em algumas ocasiões o programador necessita gerenciar de forma particular um abandono e então fazemos o uso da função TRAP.

Trap é uma função inline definida no cabeçalho e32cmn.h e pode ser definida como:


TRAP(_r, _s);

Esta função executa um conjunto de instruções C++ e retorna um inteiro com o valor do abandono (caso tenha ocorrido).


Onde:


_r = O código de abandono gerado pelas funções é salvo neste inteiro. Este inteiro precisa ser declarado antes de usar a TRAP.

_s = Conjunto de instruções C++ que serão colocadas "a prova" utilizando a TRAP. Caso estas abandonem o valor é passado para _r.

Uma alternativa à TRAP é o TRAPD, utilizado apenas por conveniência onde o inteiro que recebe o código de abandono não precisa ser declaro explicitamente.


Exemplos de uso do TRAP:

TInt err;<br>TRAP(err, FuncaoQuePodeAbandonarL());<br>if( err == KErrNone ) // não ocorreu abandono<br>{<br> // faz algo<br>}<br>else // Ocorreu abandono<br>{<br> // faz algo <br>}

Exemplo com TRAPD:

TRAPD(err, FuncaoQuePodeAbandonarL());<br>if( err == KErrorNone )<br>{<br> // faz algo<br>}<br>else<br>{<br> // faz algo<br>}

Nota: A utilização de TRAPS pelo programa aumenta significamente o tamanho do código final da aplicação e causa um certo overhead, então deve ser utilizado com cautela.

Pilha de limpeza

Considere o seguinte código:


void CMinhaClasse::CarregarAlgoL()
{
CCarro* fiat = new (ELeave) CCarro();
fiat->DirigirL();
delete fiat;
}





É feita a alocação dinâmica de um objeto do tipo CCarro e então este objeto chama o método DirigirL. Este método pode lançar uma exceção - Métodos que possam lançar exceção terminam com L - , caso uma exceção ocorra todas as variáveis automáticas do método CarregarAlgoL serão removidas incluindo neste caso o ponteiro fiat. Isto acontecendo perderemos a referência para a memória que fiat aponta - quando ocorre uma exceção não há garantia que o destrutor da classe será chamado ou que os códigos seguintes serão executados-  no exemplo, o comando delete nunca será executado. O resultado seria um vazamento de memória. Pode parecer que alguns bytes não representam muita coisa, mas para um sistema com recursos limitados e que não faz re-boot frequentemente isto pode ocasionar sérios problemas.

Para resolver problemas como este foi desenvolvido o mecanismo de limpeza da pilha ( CleanupStack ). Considere o seguinte código:


void CMinhaClasse::CarregarAlgoL()
{
CCarro* fiat = new (ELeave) CCarro();
CleanupStack::PushL( fiat );
fiat->DirigirL();
CleanupStack::PopAndDestroy();
}


Caso não tenha notado, foram adicionadas duas linhas de código que representam chamadas à métodos de CleanupStack. Neste código, caso DirigirL abandone não perderemos a referência a memória que fiat aponta. Seu uso é bastante simples, você adiciona ponteiros automáticos à pilha e na ocorrência de um abandono será chamado o destrutor do objeto que este ponteiro aponta e então sua memória será liberada através do operador User::Free.





A classe CleanupStack possui apenas  4 métodos (com suas devidas sobrecargas) todos são estáticos e bastante intuítivos.

PushL- Adiciona um ponteiro a pilha de limpeza.

Pop- Remove um ponteiro da pilha de limpeza

PopAndDestroy- Remove um ponteiro da pilha de limpeza e libera sua memória. O mesmo que realizar um CleanupStack::Pop() e então delete.


Nota 1: PushL pode gerar um abandono mas está fora do escopo deste artigo discutir isto, para maior informações consulte [1].

Nota 2: Atributos membros de classe não devem ser adicionados a pilha de limpeza pois é função da sua classe realizar a deleção. Sendo colocado na pilha de limpeza poderia ocorrer uma dupla deleção o que pode ocasionar problemas.

Construção em duas fases

Construtores e destrutores não podem retornar um valor e por isso não pode abandonar. Pensando nisso, foi desenvolvido a contrução em duas fases para evitar que construtores gerem abandonos. Funções que possam gerar um abandono devem ser chamadas no ConstructL (L no final é uma convenção de nome que significa que essa função pode abandonar) ao invés do construtor padrão C++. Qualquer outra inicialização que não possa abandonar pode ser inicializada normalmente no construtor padrão.

Exemplo:


void CMinhaAplicao::ConstructL(const TRect& aRect)
{
CMinhaAplicacao* self = CMinhaAplicacao(aRect);
CleanupStack::PushL(self);
self->ConstructL(aRect) ;
CleanupStack::Pop(self);
return self;
}
 
CMinhaAplicacao::CMinhaAplicacao()
{
iVariavel = 1;
}






Leitura complementar

[1] - Pilha de limpeza - Cleanup Stack
Construtor em 2 fases
Gerência de memória

98 page views in the last 30 days.

Was this page helpful?

Your feedback about this content is important. Let us know what you think.

 

Thank you!

We appreciate your feedback.

×