Python Error Handling: încercați / cu excepția / else / în sfârșit în 2026

Gestionarea erorilor separă „codul care funcționează pe mașina ta” de „codul care supraviețuiește producției”. try / except din Python pare simplu, dar forma completă cu patru cuvinte cheie — try / except / else / finally — codifică o cantitate surprinzătoare de structură pe care majoritatea tutorialelor o sărită.

Acest ghid acoperă: ce înseamnă de fapt fiecare cuvânt cheie, cele șase modele pe care le veți vedea în fiecare bază de cod backend, când să vă definiți propriile excepții și cele trei anti-modele care lasă erorile să treacă peste testele dvs.

Cele patru cuvinte cheie, exact

Clauza „else” este subutilizată. Se spune „acest următor bit depinde de succesul încercării, dar nu vreau să fie protejat de același lucru, cu excepția”. Este locul potrivit pentru continuarea căii fericite — punerea lui în „încercați” prinde accidental excepții fără legătură de la „navă(rezultat)”.

Cele șase modele

1. Reîncercați în cazul eșecului tranzitoriu

Regula: reîncercați NUMAI în cazul erorilor tranzitorii (rețea, timeout, 429, 503). Nu reîncercați niciodată pe ValueError, KeyError, TypeError - acestea sunt erori de cod, iar reîncercarea rulează eroarea de trei ori.

2. Păzește cu altfel

else garantează că fișierul a fost deschis cu succes ȘI curățarea scopurilor cu with. Observație: process() poate genera ValueError — care se va propaga, NU va fi capturat de cu excepția FileNotFoundError.

3. Curățare cu finally (înainte de a exista cu)

În codul modern, ați folosi with db.connect() ca conn: — with este zahărul peste try / finally pentru cazul obișnuit de curățare. Ajungeți la finally explicit numai atunci când resursa nu acceptă protocolul de gestionare a contextului.

4. Re-raise cu context adăugat

ridicați NewException(...) from e lanțuri excepția originală pe cea nouă, astfel încât traceback să arate AMBELE. Nu scrieți niciodată raise NewException(str(e)) — care elimină traceback-ul original.

5. Prinde cea mai restrânsă excepție pe care o poți

Regula: cu cât este mai îngust, cu atât mai bine. Dacă nu știți ce proces poate genera, rulați-l și aflați. „cu excepția excepției:” este un miros de cod în 90% din timp.

6. raise inside except — re-raise curat

Bare raise păstrează intactă traseul original. Niciodată raise e (Python 3 este inteligent în privința asta, dar bare raise este forma idiomatică).

Excepții personalizate — când merită

Definiți-vă propria clasă de excepție atunci când:

1. Apelanții trebuie să „excepte MyError:” în mod specific (adică aveți un API apelabil și utilizatorii trebuie să se ramifică pe tipul de eșec).

2. Biblioteca/serviciul dvs. generează mai multe erori legate de context.

Acum apelanții pot prinde la scară largă (cu excepția PaymentError) sau restrâns (except CardDeclinedError). Atributele structurate ale excepției (e.card_last4) permit gestionatorilor de erori să construiască UX util fără a analiza mesajele de excepție.

Anti-model: definește o excepție personalizată care există doar pentru a fi ridicată o dată și niciodată prinsă. Acesta este doar raise ValueError("..."). Excepțiile personalizate își câștigă greutatea din faptul că sunt prinse.

Trei anti-modele care ascund bug-uri

Anti-model 1: Bare, cu excepția

Bare except captează semnale care ar trebui să iasă din program (Ctrl-C, sys.exit, MemoryError). Nu scrie niciodată asta. Dacă doriți cu adevărat să capturați fiecare excepție nefatală, utilizați „except Exception:” — care prinde încă prea mult, dar cel puțin respectă Ctrl-C.

Anti-model 2: Tăcere fără înregistrare

Fiecare excepție prinsă ar trebui fie gestionată (cu o anumită rezervă) fie înregistrată. pass într-o excepție este o eroare în mișcare lentă — codul pare să funcționeze în timp ce elimină datele în tăcere.

Anti-model 3: cu excepția excepției: în jurul tuturor

Problemă: dacă stripe.charge a reușit, dar send_receipt nu a reușit, clientul a fost taxat ȘI tu ai înghițit eroarea. cu excepția acoperă patru moduri diferite de defecțiune și nu le puteți deosebi.

Remediere: restrângeți domeniul de încercare + ramificați cu excepția limitei modulului.

Fiecare încercare acoperă O operațiune. Fiecare cu excepția știe ce să facă în legătură cu ACEST eșec specific. Aceasta este gestionarea erorilor la nivel de producție.

O bună gestionare a erorilor este mai mult design decât sintaxă. try / except / else / finally vă oferă instrumentele; disciplina este alegerea corectă, cu excepția tipului, cea mai restrânsă sferă de încercare posibilă și niciodată să tacă erorile pe care nu le înțelegeți.

Următorul pas: Foundations track are 10 lecții despre gestionarea excepțiilor, excepții personalizate și declarația with — cu Python real rulând în browser.