Tôi nghĩ điểm liên quan đến try...except...else là việc sử dụng nó là một sai lầm dễ dàng để tạo trạng thái không nhất quán thay vì sửa lỗi. Nó không phải là nó nên tránh bằng mọi giá, nhưng nó có thể phản tác dụng.
xem xét:
try:
file = open('somefile','r')
except IOError:
logger.error("File not found!")
else:
# Some file operations
file.close()
# Some code that no longer explicitly references 'file'
Sẽ thật tốt đẹp để nói rằng khối trên ngăn chặn mã từ cố gắng để truy cập vào một tập tin đó không tồn tại, hoặc một thư mục mà người dùng không có quyền truy cập, và để nói rằng mọi thứ được đóng gói bởi vì nó nằm trong khối try...except...else. Nhưng trong thực tế, rất nhiều mã trong các hình thức nêu trên thực sự nên xem xét như thế này:
try:
file = open('somefile','r')
except IOError:
logger.error("File not found!")
return False
# Some file operations
file.close()
# Some code that no longer explicitly references 'file'
Bạn thường lừa mình bằng cách nói rằng vì file không còn được nhắc đến trong phạm vi, nó không quan trọng để đi vào mã sau khối, nhưng trong nhiều trường hợp một cái gì đó sẽ đến nơi mà nó chỉ là không ổn. Hoặc có thể một biến sau đó sẽ được tạo trong khối else không được tạo trong khối except.
Đây là cách tôi sẽ phân biệt if...else từ try...except...else. Trong cả hai trường hợp, người ta phải làm cho các khối song song trong hầu hết các trường hợp (các biến và trạng thái được đặt trong một nên được đặt ở vị trí khác) nhưng ở phần sau, các lập trình viên thường không, có khả năng là không thể hoặc không liên quan. Trong những trường hợp như vậy, nó thường sẽ làm cho toàn bộ ý nghĩa hơn nhiều để trở về người gọi hơn là cố gắng và tiếp tục làm việc xung quanh những gì bạn nghĩ rằng bạn sẽ có trong kịch bản trường hợp tốt nhất.
Nguồn
2009-05-14 21:50:38
Xin chào dF. Trong một vùng nguy hiểm tương tự: a = b = c = 2 –
Còn về vòng lặp, chúng có thể chạy mãi mãi khi bạn không muốn chúng. Có vẻ hơi quá tải nếu bạn loại bỏ các tính năng ngôn ngữ có khả năng gây nguy hiểm. – Milhous