Há situações em que você pode usá-las, mas elas devem ser muito raras. As situações em que eu poderia usar um incluem:
registro de exceção; dependendo do contexto, você pode querer publicar uma exceção não tratada ou uma mensagem.
situações técnicas em loop, como renderização ou processamento de som ou um retorno de chamada da caixa de listagem, em que o próprio comportamento demonstrará o problema, lançar uma exceção apenas atrapalhará e o registro da exceção provavelmente resultará em milhares de mensagens "com falha no XXX" .
programas que não podem falhar, embora ainda devam ao menos registrar alguma coisa.
para a maioria dos aplicativos winforms, descobri que basta ter uma única instrução try para cada entrada do usuário. Eu uso os seguintes métodos: (AlertBox é apenas um invólucro rápido MessageBox.Show)
public static bool TryAction(Action pAction)
{
try { pAction(); return true; }
catch (Exception exception)
{
LogException(exception);
return false;
}
}
public static bool TryActionQuietly(Action pAction)
{
try { pAction(); return true; }
catch(Exception exception)
{
LogExceptionQuietly(exception);
return false;
}
}
public static void LogException(Exception pException)
{
try
{
AlertBox(pException, true);
LogExceptionQuietly(pException);
}
catch { }
}
public static void LogExceptionQuietly(Exception pException)
{
try { Debug.WriteLine("Exception: {0}", pException.Message); } catch { }
}
Então, todo manipulador de eventos pode fazer algo como:
private void mCloseToolStripMenuItem_Click(object pSender, EventArgs pEventArgs)
{
EditorDefines.TryAction(Dispose);
}
ou
private void MainForm_Paint(object pSender, PaintEventArgs pEventArgs)
{
EditorDefines.TryActionQuietly(() => Render(pEventArgs));
}
Teoricamente, você pode ter o TryActionSilently, que pode ser melhor para renderizar chamadas, para que uma exceção não gere uma quantidade infinita de mensagens.