Sử dụng kỹ lưỡng các câu lệnh 'if' hoặc các khối 'try/catch'?

Question

Hãy cho tôi một số suy nghĩ của bạn về việc thực hành mã hóa tốt hơn/tạo mã hiệu quả hơn/trông đẹp hơn/bất cứ điều gì: Tăng và cải thiện khả năng sử dụng của bạn nếu các câu lệnh dự đoán và nắm bắt các vấn đề tiềm ẩn? Hoặc đơn giản là sử dụng tốt thử/nắm bắt nói chung?

Hãy nói điều này là dành cho Java (nếu nó quan trọng).

Chỉnh sửa: Tôi hiện đang tự chuyển đổi khỏi một số thực tiễn mã hóa hiện tại đã bị thừa nhận và bị hạn chế, nhưng tôi hơi rách về sự cần thiết phải thực hiện một vài điểm (như thế này). Tôi chỉ đơn giản là yêu cầu một số quan điểm về điều này. Không phải là một cuộc tranh luận.

Answer 1

cuộc tranh luận này (2003) là tốt:

http://www.joelonsoftware.com/items/2003/10/13.html

http://nedbatchelder.com/blog/200310/joel_on_exceptions.html

Answer 2

My 2p: Sử dụng try/catch là tốt nhất:

• nó làm cho nó hoàn toàn rõ ràng đối với lập trình khác mà bạn đang làm xử lý
• trình biên dịch ngoại lệ hiểu những gì bạn đang làm và có thể thực hiện biên dịch thích hợp hơn kiểm tra thời gian cho bạn

Theo kinh nghiệm của tôi, việc phân biệt xử lý lỗi từ logic nghiệp vụ trở nên khó khăn hơn.

Answer 3

if khối hơi nhanh hơn; nếu bạn không cần một tá trong số đó, thì đó là ý tưởng hay hơn try/catches. Ngoại lệ phải là ngoại lệ, không phải mỗi khi mã chạy. Tôi sử dụng Ngoại lệ cho các sự kiện hiếm gặp như ngắt kết nối máy chủ (mặc dù chúng xảy ra vài lần mỗi ngày) và các khối if cho bất kỳ biến có thể điều khiển nào của tôi.

Answer 4

Tôi nghĩ rằng nếu báo cáo là tốt hơn. Bạn không thể bao quanh tất cả các dòng mã với một try..catch (bạn cũng có thể nhưng bạn không nên làm điều đó). Bạn có thể bao quanh một khối mã với try catch nhưng không phải mọi dòng.

Và ngoại lệ làm chậm mọi thứ.

Answer 5

Bất kể bạn đang viết mã nào, bạn sẽ sử dụng cả hai. Tôi không thể nói cho thời gian chạy Java, nhưng trên thời gian chạy .NET có một hit hiệu suất liên quan đến việc sử dụng các khối try-catch. Kết quả là, tôi cố gắng sử dụng chúng chỉ trong các lĩnh vực mà tôi đã có một cách rõ ràng để xử lý các trường hợp ngoại lệ một lần bị bắt (ngay cả khi nó chỉ đăng nhập sự tồn tại của một vấn đề).

Nếu bạn thấy mình sử dụng nhiều khối try-catch hoặc if-else chặn trong mã của bạn, hoặc phương pháp của bạn có xu hướng khá dài, hãy xem xét tái cấu trúc mã vào một số lượng lớn các phương thức nhỏ hơn. Mục đích của logic của bạn sẽ dễ theo dõi hơn - cũng như kiểm tra đơn vị dễ dàng hơn.

Answer 6

Từ những gì tôi đã được các nhà phát triển và nhà phân tích có kinh nghiệm phát biểu, thử/nắm bắt được hướng đối tượng hơn và nếu có nhiều thủ tục hơn.

Cá nhân tôi không quan tâm.

Tôi biết thực tế là thử/bắt chậm hơn và gây ra hiệu suất, nhưng nếu tôi sử dụng một tá ifs để xác thực trước khi tôi có thể làm những gì tôi muốn, tôi sẽ luôn sử dụng try/catch để lưu vào số dòng mã.

Nó làm cho cuộc sống của tôi dễ dàng hơn nhiều để không phải xác nhận bất cứ điều gì và nếu tuyên bố không thành công, chỉ cần làm những gì tôi đã làm trong khối 'khác' của tôi ... trong khối 'catch' của tôi.

Đôi khi, tôi rõ ràng kèm theo một số câu lệnh if trong try/catch, nhưng anyways.

Tôi sử dụng nếu khi chỉ có một số ít thứ để xác thực (1 hoặc 2) trước khi thực hiện những gì tôi cần làm.

Answer 7

Có một điều chưa được đề cập ở đây.

Với câu lệnh if-else, mỗi khi mã chạy, ít nhất 1 điều kiện được đảm bảo sẽ được đánh giá được thực thi. Tôi chắc rằng tất cả chúng ta đều biết cách hoạt động của if-else-elseif, nhưng phải rõ ràng ... nếu phần của câu lệnh sẽ luôn được đánh giá, nếu sai thì sau đó khác-nếu được đánh giá, và cứ thế cho đến khi chỉ có khác thì còn lại để đánh giá.

Vì vậy, việc sử dụng câu lệnh if-else sẽ ảnh hưởng đến hiệu suất của bạn. Không đáng kể (trong hầu hết các trường hợp), nhưng nó mất thời gian CPU để thực hiện các đánh giá.

câu lệnh try-catch và sửa tôi nếu tôi sai, không được xem xét trong thời gian chạy cho đến khi chúng được yêu cầu (nghĩa là ngoại lệ được ném). Vì vậy, chỉ đơn giản là gói mã của bạn trong một thử-catch sẽ không ảnh hưởng đến hiệu suất cho đến khi một ngoại lệ thực sự bị bắt bởi nó.

Ngoài ra, nó không phải là đánh bắt gây ra hiệu suất trúng, nhưng ném.

Và một điểm chính cần làm là, các câu lệnh try-catch KHÔNG BAO GIỜ được sử dụng cho logic điều kiện. Chúng chỉ nên được sử dụng cho những gì chúng được thiết kế cho: xử lý ngoại lệ!

Bắt ngoại lệ là điều cần thiết, nếu bạn biết phải làm gì với chúng. Nếu bạn không có cách xử lý đúng ngoại lệ thì bạn nên để nó đi, vì một số mã tiếp tục chuỗi có thể có cách tốt hơn để xử lý nó.

Một ý tưởng hay là có trình xử lý ngoại lệ ở cấp cao nhất tuyệt đối của ứng dụng để bắt ngoại lệ trước khi người dùng nhìn thấy. Trong ASP.NET bạn có thể làm điều này trong sự kiện Application_Error của global.asax. Trong các ngôn ngữ khác/môi trường bạn sẽ làm như vậy trong vòng lặp chính của bạn, bất cứ điều gì có thể được.

Nhưng lưu ý, có một số trường hợp ngoại lệ luôn bị bỏ rơi tốt nhất. Đôi khi, khi ngoại lệ xảy ra, đó là chỉ báo cho biết trạng thái đơn đăng ký của bạn đã bị xâm phạm nghiêm trọng và không thể tin cậy được. Điều an toàn duy nhất cần làm là giết và khởi động lại.

Answer 8

@PersonalPerson - Xin lỗi, nhưng đây chỉ là viết mã lười. Thay vì sử dụng try-catch vì có quá nhiều câu lệnh if, tại sao không refactor mã của bạn (tức là đặt logic xác nhận của bạn theo phương thức riêng của nó). Điều này sẽ giữ cho mã của bạn sạch hơn và dễ đọc hơn và duy trì các phương pháp hay nhất để thực hiện.

Không bao giờ cố gắng viết mã của bạn để đạt được ít nhất số dòng. Điều này sẽ luôn luôn kết thúc tồi tệ. Chắc chắn bạn có thể tìm thấy một cách thanh lịch hơn để viết một cái gì đó mà bạn bè coder của bạn sẽ ooh và aah tại, nhưng nó chỉ làm cho mọi thứ ít dễ đọc hơn.

Tôi xin thề, tôi đã làm việc với mã của bạn trước đây và nó làm tôi đau đầu.

Answer 9

Sử dụng ngoại lệ là phương pháp phổ biến để thông báo cho một phần mã khác có điều gì đó sai xảy ra theo cách được kết hợp lỏng lẻo. Hãy tưởng tượng rằng nếu bạn muốn xử lý một số điều kiện đặc biệt bằng cách sử dụng nếu .. nad else .. bạn cần phải chèn vào một phần khác nhau của mã của bạn một số biến tùy ý và các công cụ khác mà có lẽ sẽ dễ dàng dẫn đến có mã spaghetti ngay sau đó.

Hãy tưởng tượng rằng bạn đang sử dụng bất kỳ thư viện/gói bên ngoài nào và tác giả đã quyết định đặt mã của mình theo cách tùy ý khác để xử lý các trạng thái sai - nó sẽ buộc bạn phải điều chỉnh theo cách của nó. ví dụ bạn sẽ cần phải kiểm tra xem các phương thức cụ thể có trả về true hay false hay bất cứ thứ gì.

Sử dụng ngoại lệ khiến lỗi xử lý dễ dàng hơn nhiều - bạn chỉ giả định rằng nếu xảy ra lỗi - mã khác sẽ ném ngoại lệ, vì vậy bạn chỉ cần quấn mã trong khối thử và xử lý ngoại lệ có thể theo cách của riêng bạn.