Usando try vs if em python

Existe uma justificativa para decidir qual tryou quais ifconstruções usar ao testar a variável para ter um valor?

Por exemplo, há uma função que retorna uma lista ou não retorna um valor. Quero verificar o resultado antes de processá-lo. Qual das alternativas a seguir seria mais preferível e por quê?

result = function();
if (result):
    for r in result:
        #process items

ou

result = function();
try:
    for r in result:
        #process items
except TypeError:
    pass;

Discussão relacionada:

Verificando a existência de membros em Python

Você costuma ouvir que o Python incentiva o estilo EAFP ("é mais fácil pedir perdão do que permissão") sobre o estilo LBYL ("veja antes de pular"). Para mim, é uma questão de eficiência e legibilidade.

No seu exemplo (digamos que, em vez de retornar uma lista ou uma sequência vazia, a função retornasse uma lista ou None), se você espera que 99% do tempo resultrealmente contenha algo iterável, eu usaria a try/exceptabordagem. Será mais rápido se as exceções forem realmente excepcionais. Se resultfor Nonemais de 50% do tempo, o uso ifprovavelmente será melhor.

Para suportar isso com algumas medidas:

>>> import timeit
>>> timeit.timeit(setup="a=1;b=1", stmt="a/b") # no error checking
0.06379691968322732
>>> timeit.timeit(setup="a=1;b=1", stmt="try:\n a/b\nexcept ZeroDivisionError:\n pass")
0.0829463709378615
>>> timeit.timeit(setup="a=1;b=0", stmt="try:\n a/b\nexcept ZeroDivisionError:\n pass")
0.5070195056614466
>>> timeit.timeit(setup="a=1;b=1", stmt="if b!=0:\n a/b")
0.11940114974277094
>>> timeit.timeit(setup="a=1;b=0", stmt="if b!=0:\n a/b")
0.051202772912802175

Portanto, enquanto uma ifdeclaração sempre lhe custa, é quase livre configurar um try/exceptbloco. Mas quando Exceptionrealmente ocorre, o custo é muito maior.

Moral:

• É perfeitamente aceitável (e "pitônico") usar try/exceptno controle de fluxo,
• mas faz mais sentido quando Exceptions são realmente excepcionais.

Nos documentos do Python:

EAFP

Mais fácil pedir perdão do que permissão. Esse estilo comum de codificação Python pressupõe a existência de chaves ou atributos válidos e captura exceções se a suposição for falsa. Este estilo limpo e rápido é caracterizado pela presença de muitos trye exceptdeclarações. A técnica contrasta com o estilo LBYL comum a muitos outros idiomas, como C.

Sua função não deve retornar tipos mistos (ou seja, lista ou sequência vazia). Ele deve retornar uma lista de valores ou apenas uma lista vazia. Então você não precisaria testar nada, ou seja, seu código é recolhido para:

for r in function():
    # process items

Ignore minha solução se o código que forneço não for óbvio à primeira vista e você precisar ler a explicação após o exemplo de código.

Posso assumir que o "nenhum valor retornado" significa que o valor de retorno é Nenhum? Se sim, ou se "no value" for False em termos de booleano, você pode fazer o seguinte, pois seu código trata essencialmente "no value" como "não iterate":

for r in function() or ():
    # process items

Se function()retornar algo que não é True, você itera sobre a tupla vazia, ou seja, não executa iterações. Isto é essencialmente LBYL.

Seu segundo exemplo está quebrado - o código nunca lançará uma exceção TypeError, pois você pode percorrer as strings e as listas. A iteração através de uma string ou lista vazia também é válida - ele executará o corpo do loop zero vezes.

Qual das alternativas a seguir seria mais preferível e por quê?

Look Before You Leap é preferível neste caso. Com a abordagem de exceção, um TypeError poderia ocorrer em qualquer lugar do corpo do loop e seria pego e jogado fora, o que não é o que você deseja e tornará a depuração complicada.

(Porém, concordo com Brandon Corfman: retornar Nenhum para 'sem itens' em vez de uma lista vazia está quebrado. É um hábito desagradável de codificadores Java que não devem ser vistos em Python. Ou Java.)

Geralmente, a impressão que tive é que as exceções devem ser reservadas para circunstâncias excepcionais. Se o resultesperado é que nunca fique vazio (mas pode ser, se, por exemplo, um disco travou, etc.), a segunda abordagem faz sentido. Se, por outro lado, um vazio resulté perfeitamente razoável em condições normais, testá-lo com uma ifdeclaração faz mais sentido.

Eu tinha em mente o cenário (mais comum):

# keep access counts for different files
file_counts={}
...
# got a filename somehow
if filename not in file_counts:
    file_counts[filename]=0
file_counts[filename]+=1

em vez do equivalente:

...
try:
    file_counts[filename]+=1
except KeyError:
    file_counts[filename]=1

bobince sabiamente ressalta que agrupar o segundo caso também pode capturar TypeErrors no loop, o que não é o que você deseja. Se você realmente deseja usar uma tentativa, pode testar se é iterável antes do loop

result = function();
try:
    it = iter(result)
except TypeError:
    pass
else:
    for r in it:
        #process items

Como você pode ver, é bastante feio. Eu não sugiro, mas deve ser mencionado para ser completo.

No que diz respeito ao desempenho, usar o bloco try para código que normalmente não gera exceções é mais rápido do que usar a instrução if toda vez. Portanto, a decisão depende da probabilidade de casos excecionais.

Como regra geral, você nunca deve usar try / catch ou qualquer exceção para manipular itens para controlar o fluxo. Mesmo que a iteração dos bastidores seja controlada através do aumento de StopIterationexceções, você ainda deve preferir seu primeiro trecho de código ao segundo.