Uma das apresentações interessantes a que assisti foi do conhecido David Platt, “Exception Handling Best Practices“. A sessão podia ter sido melhor, mas uma vez que o tratamento correcto de excepções é sempre um desafio, acabou por ser uma boa escolha (numa outra sessão sobre transacções, Jubal Löwy chegou a comentar que “nunca ninguém fez tratamento de erros a sério” – e depois provou-o).
Vou referir apenas duas curioridades de entre os temas que ele abordou, o “overthrowing” de excepções, e um possível problema de segurança relacionado com a forma como são tratadas.
Em relação ao Overthrowing, a apresentação foi ilustrada com um exemplo muito simples, o Int32.Parse. Mostrou uma pequena aplicação WinForms que comparava o desempenho do Int32.Parse com o do Int32.TryParse. O TryParse é uma novidade do .Net 2.0, e caso a string recebida não seja um valor numérico, devolve false em vez de gerar uma excepção. Comparando o desempenho de 100 execuções sequenciais de ambos os métodos, o Int32.Parse é ligeiramente mais rápido, como esperado.
Adicione-se 2% de erros, e o Int32.Parse passa a ter um desempenho muito inferior. E com 50% de erros, o teste passava a demorar muitos segundos. Muito ilustrativo, o exemplo. Ter muita atenção a isto, e em situações que – em termos relativos – sejam frequentemente geradas excepções, deve equacionar-se fortemente a realização de testes que as evitem.
A segunda curiosidade é um problema de segurança relacionado com uma funcionalidade do VB.NET apenas, os “Exception Filters“, funções devolvem bool e são invocadas para o runtime determinar se um determinado handler deve realmente tratar uma excepção. Sabendo-se isto, veja-se o seguinte exemplo (que retirei daqui):
WindowsImpersonationContext ctx = identity.Impersonate();
try { DoWork(); } finally { ctx.Undo(); }
Se tivermos este código numa biblioteca de classes, e for gerada uma excepção em “DoWork()“, o runtime vai percorrer o call stack à procura de um Exception Handler. Alguém que esteja a utilizar a nossa biblioteca, em VB.NET, e desenvolva um Exception Filter, nesse Exception filter vai estar a executar código no contexto do utilizador “impersonado“… o que pode não ser o pretendido se este tiver permissões elevadas. E como esta, existem outras situações em que se podem gerar problemas de segurança.
Recorde-se que o finally só vai ser executado na segunda vez que o runtime percorre o call stack…
Não sei se isto é novidade para vocês, era para mim. 🙂
jota
Ps: a propósito de segurança, foi publicada a primeira versão do “Web Services Security Patterns“, um novo conjunto de recomendações. Inclui cenários de Intranet e Intranet, formas de autenticação e brokering, etc. Muito interessante, e disponível em Word e CHM. Está no workspace de Service Orientation Patterns.
