Verwenden Sie try Ausnahme/Catch in define-Methode oder aufrufende Methode?

Question

Welcher der Teilecodes ist rational oder logisch?
Part-1:

def foo(): 
    try: 
     pass # some process 
    except Exception as e: 
     print(e) 
foo() 

Part-2:

def foo(): 
    pass # some process 
try: 
    foo() 
except Exception as e: 
    print(e) 

Answer 1

Es auf welche foo hängt der Fall ist, und die Art der Exception, würde ich sagen.

Sollte der Anrufer damit umgehen oder sollte die Methode?

Betrachten wir zum Beispiel das folgende Beispiel:

def try_get_value(registry, key): 
    try: 
     return registry[key] 
    except KeyError: 
     return None 

Diese Funktion wird versuchen, einen Wert aus einem Wörterbuch über ihren Schlüssel zu holen. Wenn der Wert nicht vorhanden ist, sollte None zurückgegeben werden.

Die Methode sollte KeyError verarbeiten, da sie in diesem Fall None zurückgeben muss, um dem erwarteten Verhalten zu entsprechen. (Es ist die responsAbility Methode, um diesen Fehler zu fangen)

Aber denken Sie an anderen Ausnahmetypen, wie TypeError (zum Beispiel, wenn die Registrierung ist kein dict).

Warum sollte unsere Methode damit umgehen? Das ist der Anrufer versaut. Er sollte damit umgehen, und er sollte sich darum sorgen.

Außerdem, was kann unsere Methode tun, wenn wir solche Exception bekommen? Das können wir aus diesem Bereich nicht bewältigen.

try_get_value hat eine einfache Aufgabe: um einen Wert aus der Registrierung (eine Standard, wenn es keine gibt). Es ist nicht dafür verantwortlich, dass der Anrufer die Regeln bricht.

So fangen wir nicht TypeError weil es ist nicht unsere Verantwortung.

daher den Code des Anrufers kann wie etwa wie folgt aussehen:

try: 
    value = try_get_value(reg, 'some_key') 
    # Handle value 
except TypeError: 
    # reg is not a dict, do something about it... 

---

P. S.: Es kann Zeiten geben, wenn unsere foo-Methode einige Bereinigung durchführen muss, wenn ein unerwarteter Exit vorliegt (z. B. hat es einige Ressourcen zugeordnet, die undicht würden, wenn nicht geschlossen).

In diesem Fall sollte foo die Ausnahmen abfangen, nur so kann es seinen Zustand entsprechend beheben, sollte aber dann raise sie wieder an den Aufrufer.

Answer 2

Ich denke, der erste Teil ist sauberer und eleganter. Dies ist auch logischer, da Sie als Implementierer der Funktion alle Ausnahmen behandeln möchten, die sie auslösen, anstatt sie dem Client oder dem Aufrufer zu überlassen. Selbst wenn Sie der einzige sein werden, der die Methode verwendet, möchten Sie immer noch Ausnahmen in der Funktion behandeln, da Sie sich in Zukunft vielleicht nicht mehr erinnern können, welche Ausnahme es auslöst.