Não lance exceções no destrutor

Existem boas práticas de programação que não são ensinadas nos manuais, sendo descobertas com a experiência. 

Uma boa prática, pelo menos em se tratando de Delphi, é o de não lançar exceções em destrutores. Isso evita termos que espalhar um tratamento para esse tipo de falha por todo o nosso código.

Vejamos um exemplo:

type

  TDoc = class

  ...

  end;

destructor TDoc.Destroy;

begin

  raise Exception.Create('Fail');

end;

type

  TSuperDoc = class

  private

    FDoc: TDoc;

    FList: TList;

  ...

  end;

destructor TSuperDoc.Destroy;

begin

  try

    FDoc.Free;

  except

  end;

  FList.Free;

end;

           

O fato de lançarmos exceções no destrutor de TDoc nos obriga a tratarmos esse tipo de problema no destrutor de TSuporDoc, para não termos nenhum memory leak. 

Em outro post, falarei sobre como economizar declarações try... finally.

Stack Trace no Delphi

Nesta semana, trabalhei na implementação do Stack Trace no Engine Runtime. Basicamente, usei a implementação do Jcl. Infelizmente o stack trace não é muito preciso, principalmente quando ele está fazendo o trace de rotinas do interpretador JavaScript, mesmo usando a opção RawTrace, que realiza toda a operação sem confiar na existência de Stack Frames. Acredito que o FastMM utilize a mesma rotina do Jcl.

Internamente, o JclDebug faz um patch no executável em tempo de execução, alterando o System.pas para possibilitar a captura do Stack trace no momento que uma exceção é gerada. Ainda não pude observar o custo de processamente dessa operação de captura.

Além do JclDebug, existem outros projetos, como o FastCode, que requerem o uso de patchs para realizarem otimizações no Delphi. Estive pensando se não seria interessante fazer o patch, em tempo de compilação, ao invés de em tempo de execução. Acredito que fazer o patch da aplicação em tempo de execução iniba um melhor uso da memória virtual por parte do sistema operacional.