Propositadamente levantando exceções para usar capturas

Para um típico if...elseempacotado com manipulação de exceção, é algo como o exemplo a seguir uma prática recomendada para evitar a duplicação de código?

try
{
    if (GetDataFromServer())
    {
        return ProcessData();
    }
    else
    {
        throw new Exception();
    }
catch(Exception ex)
{
    return null;
}

ao invés de...

try
{
    if (GetDataFromServer())
    {
        return ProcessData();
    }
    else
    {
        return null;
    }
}
catch(Exception ex)
{
    return null;
}

Sei que há um pequeno impacto no desempenho, mas estou me perguntando se isso é considerado uma prática aceitável. Atualmente, faço o segundo método - especialmente nos casos em que preciso lidar com exceções específicas de maneira diferente - mas fiquei pensando se o primeiro método é apropriado para casos simples.

O uso de manipulação de exceção para controle de fluxo é desencorajado pela Microsoft.

E uma mesa redonda sobre o tema está disponível.

Dito isto, o C # suporta isso, e suponho que depende da condição encontrada se uma exceção é a resposta mais apropriada.

O impacto no desempenho é provavelmente insignificante, conforme explicado nesta resposta .

Então, vamos com a ideia de que o desempenho não é um problema. Você está jogando System.Exception, apenas para mover a execução para a catchcláusula . Jogar um BadControlFlowThatShouldBeRewrittenExceptionprovavelmente seria um exagero.

Vamos quebrar isso. Nós temos:

• Método GetDataFromServer(os nomes dos métodos devem ser PascalCase em C #), o que pode gerar uma exceção ou retornar a bool.
• Se o resultado foi true, execute ProcessData.
• Retornar nullcaso contrário.

Parece que o método em que esse código está escrito está simplesmente fazendo muitas coisas. GetDataFromServerretornando uma boolaparência de falha de design, eu esperaria que esse método retornasse os dados obtidos do servidor , alguns IEnumerable<SomeType>que contenham 0 ou mais itens - ou seja, o caminho feliz retorna n itens em que n> 0 , não tão feliz path retorna 0 itens e o caminho infeliz explode com uma exceção não tratada, seja o que for.

Isso muda bastante a aparência do método - novamente, é difícil dizer se isso faz sentido, porque a postagem original tem apenas um ponto de saída (e, portanto, não seria compilado, pois nem todos os caminhos de código retornam um valor ), então este é apenas um palpite:

try
{
    var result = GetDataFromServer();
    return ProcessData(result);
}
catch
{
    return null;
}

Aqui você observaria ProcessDatae iteraria oe resultretornará nullse não houver nenhum item no IEnumerable.

Agora, por que o método está retornando null? O servidor estava inoperante? Existe um erro na consulta? A cadeia de conexão está usando as credenciais incorretas? Sempre que GetDataFromServerexplode com uma exceção que você não está esperando, você está engolindo, empurrando-a para debaixo do tapete e retornando um nullvalor. Eu recomendo capturar exceções específicas nesse caso e registrar todo o resto; a depuração será muito mais fácil dessa maneira.

Com uma catchcláusula geral que não captura a exceção, fica muito difícil diagnosticar qualquer coisa. Eu faria isso minimamente:

catch(Exception e)
{
    return null;
}

Agora você pode pelo menos quebrar e inspecionar ese as coisas derem errado.

TL; DR : Não, lançar e capturar exceções para controle de fluxo não é uma boa ideia.

na sua primeira resposta, há um impacto no desempenho que não precisa estar lá.

try
{
    if (GetDataFromServer())
    {
        return ProcessData();
    }
    else
    {
        throw new Exception();
    }
catch(Exception ex)
{
    return null;
}

quando você sai da instrução if para entrar na instrução Catch quando não precisa fazer o código mudar de direção, por assim dizer.

se você quiser return null; fazê-lo na instrução else, não em uma captura que é capturada após ser lançada da instrução else.

Provavelmente não se aplica ao seu código Real , mas se aplica ao código genérico que você forneceu.

Os padrões dizem que você não deve fazer isso.

Os padrões dizem que você deve fazer assim (novamente baseado no código genérico fornecido no OP)

if (GetDataFromServer())
{
    return ProcessData();
}
else
{
    Return null
}

e como você não tem nenhuma exceção específica que está capturando, não deve tentar aqui.

você deseja ver exceções quando elas ocorrerem, para que você possa corrigir o problema que cria a exceção.

Por que não o muito mais simples:

if (!GetDataFromServer()) return null;
ProcessData();

Se um manipulador de exceção existir, ele deve estar em ProcessData ()