Modo corretto di gestire le eccezioni in Python?

Question

Ho cercato altri post, in quanto ritenevo che fosse un problema piuttosto comune, ma tutte le altre domande di eccezione di Python che ho trovato non riflettevano il mio problema.

Cercherò di essere il più specifico possibile, quindi darò un esempio diretto. E per favore non pubblicare alcuna soluzione alternativa per questo problema specifico. Non sono particolarmente interessato a come è possibile inviare un'e-mail molto più bella con xyz. Voglio sapere in che modo generalmente gestisci le istruzioni dipendenti e soggette a errori.

La mia domanda è, come gestire bene le eccezioni, quelle che dipendono l'una dall'altra, ovvero: Solo se il primo passaggio ha avuto esito positivo, provare il successivo e così via. Un altro criterio è: tutte le eccezioni devono essere catturate, questo codice deve essere robusto.

Per la vostra considerazione, un esempio:

try: 
    server = smtplib.SMTP(host) #can throw an exception 
except smtplib.socket.gaierror: 
    #actually it can throw a lot more, this is just an example 
    pass 
else: #only if no exception was thrown we may continue 
    try: 
     server.login(username, password) 
    except SMTPAuthenticationError: 
     pass # do some stuff here 
    finally: 
     #we can only run this when the first try...except was successful 
     #else this throws an exception itself! 
     server.quit() 
    else: 
     try: 
      # this is already the 3rd nested try...except 
      # for such a simple procedure! horrible 
      server.sendmail(addr, [to], msg.as_string()) 
      return True 
     except Exception: 
      return False 
     finally: 
      server.quit() 

return False 

Questo sembra estremamente unpythonic a me, e la gestione di codice di errore è il triplo il codice vero e proprio business, ma d'altra parte come posso gestire diverse affermazioni dipendenti l'uno dall'altro, il significato di statement1 è un prerequisito per statement2 e così via?

Sono interessato anche alla corretta pulizia delle risorse, anche Python può gestirlo da solo.

Grazie, Tom

Answer 1

Invece di usare il try/tranne è blocco else, si potrebbe semplicemente tornare quando esso errori:

def send_message(addr, to, msg): 
    ## Connect to host 
    try: 
     server = smtplib.SMTP(host) #can throw an exception 
    except smtplib.socket.gaierror: 
     return False 

    ## Login 
    try: 
     server.login(username, password) 
    except SMTPAuthenticationError: 
     server.quit() 
     return False 

    ## Send message 
    try: 
     server.sendmail(addr, [to], msg.as_string()) 
     return True 
    except Exception: # try to avoid catching Exception unless you have too 
     return False 
    finally: 
     server.quit() 

Questo è perfettamente leggibile e Pythonic ..

Un altro modo per farlo è, piuttosto che preoccuparsi circa l'attuazione specifica, decidere come si desidera il codice a guardare, per esempio ..

sender = MyMailer("username", "password") # the except SocketError/AuthError could go here 
try: 
    sender.message("addr..", ["to.."], "message...") 
except SocketError: 
    print "Couldn't connect to server" 
except AuthError: 
    print "Invalid username and/or password!" 
else: 
    print "Message sent!" 

quindi scrivere il codice per il metodo di message(), ca prendere in mano gli errori che ci si aspetta, e aumentarne uno personalizzato e gestirli laddove è pertinente. La classe può sembrare qualcosa di simile ..

class ConnectionError(Exception): pass 
class AuthError(Exception): pass 
class SendError(Exception): pass 

class MyMailer: 
    def __init__(self, host, username, password): 
     self.host = host 
     self.username = username 
     self.password = password 

    def connect(self): 
     try: 
      self.server = smtp.SMTP(self.host) 
     except smtplib.socket.gaierror: 
      raise ConnectionError("Error connecting to %s" % (self.host)) 

    def auth(self): 
     try: 
      self.server.login(self.username, self.password) 
     except SMTPAuthenticationError: 
      raise AuthError("Invalid username (%s) and/or password" % (self.username)) 

    def message(self, addr, to, msg): 
     try: 
      server.sendmail(addr, [to], msg.as_string()) 
     except smtplib.something.senderror, errormsg: 
      raise SendError("Couldn't send message: %s" % (errormsg)) 
     except smtp.socket.timeout: 
      raise ConnectionError("Socket error while sending message") 

Answer 2

Perché non una grande prova: block? In questo modo, se viene rilevata un'eccezione, vai fino all'eccezione. E fintanto che tutte le eccezioni per i diversi passaggi sono diverse, puoi sempre dire quale parte ha generato l'eccezione.

Answer 3

In generale, si desidera utilizzare il minor numero possibile di blocchi di prova, distinguendo le condizioni di errore dai tipi di eccezioni che generano. Per esempio, ecco la mia refactoring del codice che hai postato:

try: 
    server = smtplib.SMTP(host) 
    server.login(username, password) # Only runs if the previous line didn't throw 
    server.sendmail(addr, [to], msg.as_string()) 
    return True 
except smtplib.socket.gaierror: 
    pass # Couldn't contact the host 
except SMTPAuthenticationError: 
    pass # Login failed 
except SomeSendMailError: 
    pass # Couldn't send mail 
finally: 
    if server: 
     server.quit() 
return False 

Qui, usiamo il fatto che smtplib.SMTP(), server.login(), e server.sendmail() tutto buttare diverse eccezioni per appiattire l'albero dei blocchi try-catch. Nel blocco finally testiamo esplicitamente il server per evitare di invocare quit() sull'oggetto nil.

Potremmo anche utilizzare tre sequenziali blocchi try-catch, tornando False nelle condizioni di eccezione, se ci sono sovrapposti i casi di eccezione che hanno bisogno di essere trattata separatamente:

try: 
    server = smtplib.SMTP(host) 
except smtplib.socket.gaierror: 
    return False # Couldn't contact the host 

try: 
    server.login(username, password) 
except SMTPAuthenticationError: 
    server.quit() 
    return False # Login failed 

try: 
    server.sendmail(addr, [to], msg.as_string()) 
except SomeSendMailError: 
    server.quit() 
    return False # Couldn't send mail 

return True 

Questo non è così bello, dato che devi uccidere il server in più di un posto, ma ora possiamo gestire tipi di eccezioni specifiche in modi diversi in luoghi diversi senza mantenere nessuno stato aggiuntivo.

Answer 4

Mi piace la risposta di David, ma se sei bloccato sulle eccezioni del server puoi anche controllare se il server è None o states. Ho appiattito un po 'il metodo, ma è ancora un po' disordinato ma più leggibile nella logica in basso.

Answer 5

Utilizzare solo un try-block è la strada da percorrere. Questo è esattamente ciò che sono progettati per: : eseguire la dichiarazione successiva solo se la precedente dichiarazione non ha generato un'eccezione. Per quanto riguarda i clean-up delle risorse, forse è possibile controllare la risorsa se deve essere ripulita (ad esempio myfile.is_open(), ...) Questo aggiunge alcune condizioni extra, ma verranno eseguite solo in casi eccezionali. Per gestire il caso che la stessa eccezione può essere sollevata per diversi motivi, è possibile che sia in grado di recuperare il motivo dall'eccezione.

suggerisco codice come questo:

server = None 
try: 
    server = smtplib.SMTP(host) #can throw an exception 
    server.login(username, password) 
    server.sendmail(addr, [to], msg.as_string()) 
    server.quit() 
    return True 
except smtplib.socket.gaierror: 
    pass # do some stuff here 
except SMTPAuthenticationError: 
    pass # do some stuff here 
except Exception, msg: 
    # Exception can have several reasons 
    if msg=='xxx': 
     pass # do some stuff here 
    elif: 
     pass # do some other stuff here 

if server: 
    server.quit() 

return False 

E non è raro, che gestisce il codice errore supera il codice di business. La corretta gestione degli errori può essere complessa. Ma per aumentare la manutenibilità aiuta a separare il codice aziendale dal codice di gestione degli errori.

Answer 6

Se mi fosse avrei probabilmente fare qualcosa di simile alla seguente:

try: 
    server = smtplib.SMTP(host) 
    try: 
     server.login(username, password) 
     server.sendmail(addr, [to], str(msg)) 
    finally: 
     server.quit() 
except: 
    debug("sendmail", traceback.format_exc().splitlines()[-1]) 
    return True 

Tutti gli errori vengono catturati e debug, il valore di ritorno == true in caso di successo e la connessione al server viene adeguatamente ripulita in caso di connessione iniziale.

Answer 7

vorrei provare qualcosa di simile:

class Mailer(): 

    def send_message(self): 
     exception = None 
     for method in [self.connect, 
         self.authenticate, 
         self.send, 
         self.quit]: 
      try: 
       if not method(): break 
      except Exception, ex: 
       exception = ex 
       break 

     if method == quit and exception == None: 
      return True 

     if exception: 
      self.handle_exception(method, exception) 
     else: 
      self.handle_failure(method) 

    def connect(self): 
     return True 

    def authenticate(self): 
     return True 

    def send(self): 
     return True 

    def quit(self): 
     return True 

    def handle_exception(self, method, exception): 
     print "{name} ({msg}) in {method}.".format(
      name=exception.__class__.__name__, 
      msg=exception, 
      method=method.__name__) 

    def handle_failure(self, method): 
     print "Failure in {0}.".format(method.__name__) 

Tutti i metodi (tra cui send_message, in realtà) seguono lo stesso protocollo: tornano True se ci sono riusciti, e, a meno che in realtà maniglia un'eccezione, non lo intrappolano. Questo protocollo rende anche possibile gestire il caso in cui un metodo deve indicare che non ha funzionato senza generare un'eccezione. (Se l'unico modo in cui i metodi falliscono è sollevando un'eccezione, che semplifica il protocollo.Se si ha a che fare con un sacco di stati di errore non eccezione al di fuori del metodo che ha fallito, probabilmente si ha un problema di progettazione non ha ancora funzionato.)

Lo svantaggio di questo approccio è che tutti i metodi devono utilizzare gli stessi argomenti. Non ho optato per nessuno, con l'aspettativa che i metodi che ho eliminato finiranno per manipolare i membri della classe.

L'aspetto positivo di questo approccio è tuttavia considerevole. Innanzitutto, è possibile aggiungere dozzine di metodi al processo senza rendere più complesso lo send_message.

Si può anche impazzire e fare qualcosa del genere:

def handle_exception(self, method, exception): 
    custom_handler_name = "handle_{0}_in_{1}".format(\ 
              exception.__class__.__name__, 
              method.__name__) 
    try: 
     custom_handler = self.__dict__[custom_handler_name] 
    except KeyError: 
     print "{name} ({msg}) in {method}.".format(
      name=exception.__class__.__name__, 
      msg=exception, 
      method=method.__name__) 
     return 
    custom_handler() 

def handle_AuthenticationError_in_authenticate(self): 
    print "Your login credentials are questionable." 

... anche se a quel punto, avrei potuto dire a me stesso, "auto, si sta lavorando il pattern Command piuttosto difficile, senza creare una classe di comando. Forse ora è il momento."