Tôi đang làm việc thông qua cuốn sách "Head First Python" (đây là ngôn ngữ của tôi để học trong năm nay) và tôi đã đến một phần mà họ tranh luận về hai kỹ thuật mã:
Kiểm tra đầu tiên và xử lý ngoại lệ.

Đây là một mẫu mã Python:

# Checking First
for eachLine in open("../../data/sketch.txt"):
    if eachLine.find(":") != -1:
        (role, lineSpoken) = eachLine.split(":",1)
        print("role=%(role)s lineSpoken=%(lineSpoken)s" % locals())

# Exception handling        
for eachLine in open("../../data/sketch.txt"):
    try:
        (role, lineSpoken) = eachLine.split(":",1)
        print("role=%(role)s lineSpoken=%(lineSpoken)s" % locals())
    except:
        pass

Ví dụ đầu tiên xử lý trực tiếp một vấn đề trong .splithàm. Cái thứ hai chỉ để xử lý ngoại lệ xử lý nó (và bỏ qua vấn đề).

Họ lập luận trong cuốn sách để sử dụng xử lý ngoại lệ thay vì kiểm tra trước. Đối số là mã ngoại lệ sẽ bắt tất cả các lỗi, trong đó kiểm tra trước sẽ chỉ bắt những điều bạn nghĩ về (và bạn bỏ lỡ các trường hợp góc). Tôi đã được dạy để kiểm tra trước, vì vậy bản năng nội tâm của tôi là làm điều đó, nhưng ý tưởng của họ rất thú vị. Tôi chưa bao giờ nghĩ đến việc sử dụng xử lý ngoại lệ để giải quyết các trường hợp.

Cái nào trong hai cái thường được coi là thực hành tốt hơn?

Trong .NET, thông thường là tránh lạm dụng Ngoại lệ. Một đối số là hiệu suất: trong .NET, ném một ngoại lệ là tính toán tốn kém.

Một lý do khác để tránh việc lạm dụng chúng là việc đọc mã mà phụ thuộc quá nhiều vào chúng có thể rất khó khăn. Mục blog của Joel Spolsky thực hiện tốt công việc mô tả vấn đề.

Tại trung tâm của cuộc tranh luận là trích dẫn sau đây:

Lý do là tôi coi các trường hợp ngoại lệ không tốt hơn "goto", được coi là có hại từ những năm 1960, trong đó chúng tạo ra một bước nhảy đột ngột từ điểm này sang điểm khác. Trên thực tế, chúng còn tệ hơn đáng kể so với goto:

1. Chúng vô hình trong mã nguồn . Nhìn vào một khối mã, bao gồm các hàm có thể hoặc không thể ném ngoại lệ, không có cách nào để xem ngoại lệ nào có thể được ném và từ đâu. Điều này có nghĩa là ngay cả việc kiểm tra mã cẩn thận cũng không tiết lộ các lỗi tiềm ẩn.

2. Chúng tạo quá nhiều điểm thoát có thể cho một hàm. Để viết mã chính xác, bạn thực sự phải suy nghĩ về mọi đường dẫn mã có thể thông qua chức năng của bạn. Mỗi khi bạn gọi một hàm có thể đưa ra một ngoại lệ và không bắt gặp nó ngay lập tức, bạn sẽ tạo cơ hội cho các lỗi bất ngờ gây ra bởi các hàm bị chấm dứt đột ngột, khiến dữ liệu ở trạng thái không nhất quán hoặc các đường dẫn mã khác mà bạn không nghĩ về.

Cá nhân, tôi ném ngoại lệ khi mã của tôi không thể làm những gì nó được ký hợp đồng để làm. Tôi có xu hướng sử dụng thử / bắt khi tôi sắp xử lý một cái gì đó nằm ngoài ranh giới quy trình của mình, ví dụ như một cuộc gọi SOAP, một cuộc gọi cơ sở dữ liệu, tệp IO hoặc một cuộc gọi hệ thống. Nếu không, tôi cố gắng để mã hóa phòng thủ. Đó không phải là một quy tắc khó và nhanh, nhưng đó là một thông lệ chung.

Scott Hanselman cũng viết về các ngoại lệ trong .NET ở đây . Trong bài viết này, ông mô tả một số quy tắc về ngoại lệ. Yêu thích của tôi?

Bạn không nên ném ngoại lệ cho những điều xảy ra mọi lúc. Sau đó, họ sẽ là "pháp lệnh".

Trong Python nói riêng, nó thường được coi là thực hành tốt hơn để bắt ngoại lệ. Nó có xu hướng được gọi là Dễ dàng hơn để yêu cầu sự tha thứ so với sự cho phép (EAFP), so với Look Before You Leap (LBYL). Có những trường hợp LBYL sẽ cung cấp cho bạn các lỗi tinh tế trong một số trường hợp.

Tuy nhiên, hãy cẩn thận với các tuyên bố trầnexcept: cũng như vượt quá các báo cáo, vì cả hai cũng có thể che giấu các lỗi - một cái gì đó như thế này sẽ tốt hơn:

for eachLine in open("../../data/sketch.txt"):
    try:
        role, lineSpoken = eachLine.split(":",1)
    except ValueError:
        pass
    else:
        print("role=%(role)s lineSpoken=%(lineSpoken)s" % locals())

Cách tiếp cận thực dụng

Bạn nên phòng thủ nhưng đến một điểm. Bạn nên viết xử lý ngoại lệ nhưng đến một điểm. Tôi sẽ sử dụng lập trình web làm ví dụ vì đây là nơi tôi sống.

1. Giả sử tất cả đầu vào của người dùng là xấu và chỉ viết phòng thủ đến điểm xác minh kiểu dữ liệu, kiểm tra mẫu và tiêm độc hại. Lập trình phòng thủ phải là những thứ có khả năng xảy ra rất thường xuyên mà bạn không thể kiểm soát.
2. Viết xử lý ngoại lệ cho các dịch vụ được nối mạng đôi khi có thể bị lỗi và xử lý một cách duyên dáng cho phản hồi của người dùng. Lập trình ngoại lệ nên được sử dụng cho những thứ được nối mạng đôi khi có thể bị lỗi nhưng thường rất chắc chắn VÀ bạn cần giữ cho chương trình của mình hoạt động.
3. Đừng bận tâm viết phòng thủ trong ứng dụng của bạn sau khi dữ liệu đầu vào được xác thực. Thật lãng phí thời gian và làm phồng ứng dụng của bạn. Hãy để nó nổ tung vì một trong những thứ rất hiếm không đáng để xử lý hoặc điều đó có nghĩa là bạn cần xem xét kỹ hơn về bước 1 và 2.
4. Không bao giờ viết xử lý ngoại lệ trong mã lõi của bạn không phụ thuộc vào thiết bị được nối mạng. Làm như vậy là lập trình xấu và tốn kém cho hiệu suất. Ví dụ, viết một lần thử trong trường hợp vượt ra khỏi giới hạn trong một vòng lặp có nghĩa là bạn đã không lập trình vòng lặp chính xác ở vị trí đầu tiên.
5. Hãy để mọi thứ được xử lý bằng cách ghi nhật ký lỗi trung tâm bắt ngoại lệ ở một nơi sau khi làm theo các quy trình trên. Bạn không thể bắt mọi trường hợp cạnh vì điều đó có thể là vô hạn, bạn chỉ cần viết mã xử lý hoạt động dự kiến. Đó là lý do tại sao bạn sử dụng xử lý lỗi trung tâm như là phương sách cuối cùng.
6. TDD là tốt bởi vì theo một cách nào đó là cố gắng bắt bạn mà không phình to, có nghĩa là mang lại cho bạn một số đảm bảo hoạt động bình thường.
7. Điểm thưởng là sử dụng một công cụ bao phủ mã, ví dụ Istanbul là một công cụ tốt cho nút vì điều này cho bạn thấy nơi bạn không thử nghiệm.
8. Thông báo trước cho tất cả những điều này là ngoại lệ thân thiện với nhà phát triển . Ví dụ, một ngôn ngữ sẽ ném nếu bạn sử dụng cú pháp sai và giải thích lý do. Vì vậy, các thư viện tiện ích của bạn mà phần lớn mã của bạn phụ thuộc vào.

Đây là từ kinh nghiệm làm việc trong các kịch bản nhóm lớn.

Tương tự

Hãy tưởng tượng nếu bạn mặc một bộ đồ không gian bên trong ISS TẤT CẢ thời gian. Thật khó để đi vệ sinh hay ăn uống. Nó sẽ siêu cồng kềnh bên trong mô-đun không gian để di chuyển xung quanh. Nó sẽ hút. Viết một loạt các lần thử trong mã của bạn là như thế. Bạn phải có một số điểm mà bạn nói, hey tôi đã bảo đảm ISS và các phi hành gia của tôi bên trong đều ổn, vì vậy việc mặc một bộ đồ vũ trụ cho mọi tình huống có thể xảy ra là không thực tế.

Đối số chính của cuốn sách là phiên bản ngoại lệ của mã tốt hơn bởi vì nó sẽ nắm bắt mọi thứ mà bạn có thể đã bỏ qua nếu bạn cố gắng viết kiểm tra lỗi của riêng bạn.

Tôi nghĩ rằng tuyên bố này chỉ đúng trong những trường hợp rất cụ thể - nơi bạn không quan tâm nếu đầu ra là chính xác.

Không có nghi ngờ rằng việc nâng cao ngoại lệ là một thực hành đúng đắn và an toàn. Bạn nên làm như vậy bất cứ khi nào bạn cảm thấy có điều gì đó trong trạng thái hiện tại của chương trình mà bạn (với tư cách là nhà phát triển) không thể hoặc không muốn giải quyết.

Ví dụ của bạn, tuy nhiên, là về việc bắt ngoại lệ. Nếu bạn bắt gặp một ngoại lệ, bạn không tự bảo vệ mình khỏi các tình huống mà bạn có thể đã bỏ qua. Bạn đang làm chính xác điều ngược lại: bạn cho rằng bạn đã bỏ qua bất kỳ kịch bản nào có thể gây ra loại ngoại lệ này, và do đó bạn tự tin rằng việc nắm bắt nó (và do đó ngăn không cho chương trình thoát ra, như bất kỳ ngoại lệ chưa được khai thác nào).

Sử dụng phương pháp ngoại lệ, nếu bạn thấy ValueErrorngoại lệ, bạn bỏ qua một dòng. Sử dụng phương pháp tiếp cận không ngoại lệ truyền thống, bạn đếm số lượng giá trị được trả về splitvà nếu nó nhỏ hơn 2, bạn bỏ qua một dòng. Bạn có nên cảm thấy an toàn hơn với cách tiếp cận ngoại lệ, vì bạn có thể đã quên một số tình huống "lỗi" khác trong kiểm tra lỗi truyền thống của mình và except ValueErrorsẽ bắt chúng cho bạn?

Điều này phụ thuộc vào bản chất của chương trình của bạn.

Nếu bạn đang viết, ví dụ, trình duyệt web hoặc trình phát video, một vấn đề với đầu vào sẽ không khiến nó bị sập với một ngoại lệ chưa được lưu. Tốt hơn hết là xuất ra thứ gì đó hợp lý từ xa (ngay cả khi, nói đúng ra là không chính xác) hơn là bỏ.

Nếu bạn đang viết một ứng dụng mà vấn đề chính xác (như phần mềm kinh doanh hoặc kỹ thuật), đây sẽ là một cách tiếp cận tồi tệ. Nếu bạn quên một số kịch bản phát sinh ValueError, điều tồi tệ nhất bạn có thể làm là âm thầm bỏ qua kịch bản chưa biết này và chỉ cần bỏ qua dòng. Đó là cách các lỗi rất tinh vi và tốn kém kết thúc trong phần mềm.

Bạn có thể nghĩ rằng cách duy nhất bạn có thể thấy ValueErrortrong mã này là nếu splitchỉ được trả về một giá trị (thay vì hai). Nhưng điều gì sẽ xảy ra nếu printcâu lệnh của bạn sau đó bắt đầu sử dụng một biểu thức tăng lên ValueErrortrong một số điều kiện? Điều này sẽ khiến bạn bỏ qua một số dòng không phải vì họ bỏ lỡ :, mà vì printthất bại trên chúng. Đây là một ví dụ về một lỗi tinh vi mà tôi đã đề cập trước đó - bạn sẽ không nhận thấy bất cứ điều gì, chỉ mất một số dòng.

Đề nghị của tôi là tránh bắt (nhưng không nêu ra!) Ngoại lệ trong mã nơi sản xuất đầu ra không chính xác còn tệ hơn thoát. Lần duy nhất tôi bắt gặp một ngoại lệ trong mã như vậy là khi tôi có một biểu thức thực sự tầm thường, vì vậy tôi có thể dễ dàng suy luận điều gì có thể gây ra từng loại ngoại lệ có thể.

Đối với tác động hiệu suất của việc sử dụng các ngoại lệ, nó là tầm thường (trong Python) trừ khi gặp phải các ngoại lệ thường xuyên.

Nếu bạn sử dụng ngoại lệ để xử lý các điều kiện xảy ra thường xuyên, trong một số trường hợp, bạn có thể phải trả một chi phí hiệu suất rất lớn. Ví dụ, giả sử bạn thực hiện từ xa một số lệnh. Bạn có thể kiểm tra xem văn bản lệnh của bạn vượt qua ít nhất là xác thực tối thiểu (ví dụ: cú pháp). Hoặc bạn có thể đợi một ngoại lệ được đưa ra (điều này chỉ xảy ra sau khi máy chủ từ xa phân tích cú pháp lệnh của bạn và tìm thấy sự cố với nó). Rõ ràng, trước đây là đơn đặt hàng cường độ nhanh hơn. Một ví dụ đơn giản khác: bạn có thể kiểm tra xem một số có nhanh hơn 0 ~ 10 lần so với cố gắng thực hiện phép chia hay không và sau đó bắt ngoại lệ ZeroDivisionError.

Những cân nhắc này chỉ quan trọng nếu bạn thường xuyên gửi các chuỗi lệnh không đúng định dạng đến các máy chủ từ xa hoặc nhận các đối số có giá trị bằng 0 mà bạn sử dụng để phân chia.

Lưu ý: Tôi giả sử bạn sẽ sử dụng except ValueErrorthay vì chỉ except; như những người khác đã chỉ ra, và như cuốn sách đã nói trong một vài trang, bạn không bao giờ nên sử dụng trần except.

Một lưu ý khác: cách tiếp cận không ngoại lệ thích hợp là đếm số lượng giá trị được trả về split, thay vì tìm kiếm :. Cái sau thì quá chậm, vì nó lặp lại công việc được thực hiện bởi splitvà có thể tăng gần gấp đôi thời gian thực hiện.

Theo nguyên tắc chung, nếu bạn biết một tuyên bố có thể tạo ra kết quả không hợp lệ, hãy kiểm tra điều đó và xử lý nó. Sử dụng ngoại lệ cho những điều bạn không mong đợi; những thứ "đặc biệt". Nó làm cho mã rõ ràng hơn theo nghĩa hợp đồng ("không nên là null" làm ví dụ).

Sử dụng những gì từng hoạt động tốt trong ..

• ngôn ngữ lập trình bạn đã chọn về khả năng đọc và hiệu quả của mã
• nhóm của bạn và tập hợp các quy ước mã đã thống nhất

Cả xử lý ngoại lệ và lập trình phòng thủ là những cách khác nhau để thể hiện cùng một mục đích.

TBH, không vấn đề gì nếu bạn sử dụng try/exceptmáy móc hoặc ifkiểm tra câu lệnh. Bạn thường thấy cả EAFP và LBYL trong hầu hết các đường cơ sở Python, với EAFP là phổ biến hơn một chút. Đôi khi EAFP là nhiều hơn nữa có thể đọc / thành ngữ, nhưng trong trường hợp đặc biệt này, tôi nghĩ rằng nó là tốt một trong hai cách.

Tuy nhiên...

Tôi sẽ cẩn thận khi sử dụng tài liệu tham khảo hiện tại của bạn. Một vài vấn đề rõ ràng với mã của họ:

1. Các mô tả tập tin bị rò rỉ. Các phiên bản hiện đại của CPython (một trình thông dịch Python cụ thể ) sẽ thực sự đóng nó, vì đó là một đối tượng ẩn danh chỉ có phạm vi trong vòng lặp (gc sẽ nuke nó sau vòng lặp). Tuy nhiên, các thông dịch viên khác không có sự đảm bảo này. Họ có thể rò rỉ mô tả hoàn toàn. Bạn hầu như luôn muốn sử dụng withthành ngữ khi đọc tệp trong Python: có rất ít ngoại lệ. Đây không phải là một trong số họ.
2. Việc xử lý ngoại lệ của Pokemon được tán thành khi nó che giấu các lỗi (tức là excepttuyên bố trần không bắt được một ngoại lệ cụ thể)
3. Nit: Bạn không cần parens để giải nén. Chỉ có thể làmrole, lineSpoken = eachLine.split(":",1)

Ivc có một câu trả lời tốt về điều này và EAFP, nhưng cũng đang rò rỉ mô tả.

Phiên bản LBYL không nhất thiết phải có hiệu suất như phiên bản EAFP, do đó, nói rằng việc ném ngoại lệ là "đắt về mặt hiệu suất" là sai về mặt phân loại. Nó thực sự phụ thuộc vào loại chuỗi bạn đang xử lý:

In [33]: def lbyl(lines):
    ...:     for line in lines:
    ...:         if line.find(":") != -1:
    ...:             # Nuke the parens, do tuple unpacking like an idiomatic Python dev.
    ...:             role, lineSpoken = line.split(":",1)
    ...:             # no print, since output is obnoxiously long with %timeit
    ...:

In [34]: def eafp(lines):
    ...:     for line in lines:
    ...:         try:
    ...:             # Nuke the parens, do tuple unpacking like an idiomatic Python dev.
    ...:             role, lineSpoken = eachLine.split(":",1)
    ...:             # no print, since output is obnoxiously long with %timeit
    ...:         except:
    ...:             pass
    ...:

In [35]: lines = ["abc:def", "onetwothree", "xyz:hij"]

In [36]: %timeit lbyl(lines)
100000 loops, best of 3: 1.96 µs per loop

In [37]: %timeit eafp(lines)
100000 loops, best of 3: 4.02 µs per loop

In [38]: lines = ["a"*100000 + ":" + "b", "onetwothree", "abconetwothree"*100]

In [39]: %timeit lbyl(lines)
10000 loops, best of 3: 119 µs per loop

In [40]: %timeit eafp(lines)
100000 loops, best of 3: 4.2 µs per loop

Về cơ bản, xử lý ngoại lệ được cho là phù hợp hơn với các ngôn ngữ OOP.

Điểm thứ hai là hiệu suất, bởi vì bạn không phải thực thi eachLine.findcho mỗi dòng.

Tôi nghĩ rằng lập trình phòng thủ làm tổn thương hiệu suất. Bạn cũng chỉ nên nắm bắt các ngoại lệ bạn sẽ xử lý, hãy để thời gian chạy xử lý ngoại lệ bạn không biết cách xử lý.