Đối số cho hoặc không sử dụng Thử / Bắt làm toán tử logic [đã đóng]

Tôi vừa phát hiện ra một số mã đáng yêu trong ứng dụng công ty của chúng tôi sử dụng các khối Try-Catch làm toán tử logic.
Có nghĩa là, "làm một số mã, nếu điều đó ném lỗi này, hãy thực hiện mã này, nhưng nếu điều đó ném lỗi này, hãy làm điều thứ 3 thay thế".
Nó sử dụng "Cuối cùng" là câu lệnh "khác" mà nó xuất hiện.
Tôi biết rằng điều này là sai vốn có, nhưng trước khi tôi đi chọn một cuộc chiến, tôi đã hy vọng cho một số tranh luận được suy nghĩ tốt.
Và này, nếu bạn có tranh luận về việc sử dụng Thử bắt theo cách này, xin vui lòng cho biết.

Đối với bất kỳ ai đang tự hỏi, ngôn ngữ là C # và mã được đề cập là khoảng hơn 30 dòng và đang tìm kiếm các ngoại lệ cụ thể, nó không xử lý TẤT CẢ các ngoại lệ.

Xử lý ngoại lệ có xu hướng là một cách tốn kém để xử lý kiểm soát luồng (chắc chắn cho C # và Java).

Thời gian chạy thực hiện khá nhiều công việc khi một đối tượng ngoại lệ được xây dựng - kết hợp dấu vết ngăn xếp với nhau, tìm ra nơi xử lý ngoại lệ và hơn thế nữa.

Tất cả chi phí này trong bộ nhớ và tài nguyên CPU không cần phải mở rộng nếu các câu lệnh điều khiển luồng được sử dụng cho điều khiển luồng.

Ngoài ra, có một vấn đề ngữ nghĩa. Các ngoại lệ dành cho các tình huống đặc biệt, không phải cho kiểm soát dòng chảy thông thường. Người ta nên sử dụng xử lý ngoại lệ để xử lý các tình huống không dự đoán / ngoại lệ, không phải như luồng chương trình thông thường, bởi vì nếu không, một ngoại lệ chưa được xử lý sẽ cho bạn biết ít hơn nhiều.

Ngoài hai điều này, còn có vấn đề của những người khác đọc mã. Sử dụng các ngoại lệ theo cách như vậy không phải là điều mà hầu hết các lập trình viên sẽ mong đợi, vì vậy khả năng đọc và mã của bạn dễ hiểu như thế nào. Khi nhìn thấy "Ngoại lệ", người ta nghĩ - điều gì đó tồi tệ đã xảy ra, điều gì đó không được phép xảy ra bình thường. Vì vậy, sử dụng các ngoại lệ theo cách này chỉ là khó hiểu.

Tôi vừa phát hiện ra một số mã đáng yêu trong ứng dụng của công ty chúng tôi sử dụng các khối Try-Catch làm toán tử logic. Có nghĩa là, "làm một số mã, nếu điều đó ném lỗi này, hãy thực hiện mã này, nhưng nếu điều đó ném lỗi này, hãy làm điều thứ 3 thay thế". Nó sử dụng "Cuối cùng" là câu lệnh "khác" mà nó xuất hiện. Tôi biết rằng điều này vốn đã sai ...

Làm sao bạn biết điều đó? Tôi đã từ bỏ tất cả các loại "kiến thức" đó và bây giờ chỉ tin rằng mã đơn giản nhất là tốt nhất. Giả sử bạn muốn chuyển đổi một chuỗi thành Tùy chọn trống nếu phân tích cú pháp thất bại. Không có gì sai với:

try { 
    return Optional.of(Long.valueOf(s)); 
} catch (NumberFormatException) { 
    return Optional.empty(); 
}

Tôi hoàn toàn không đồng ý với cách giải thích thông thường của "Ngoại lệ là cho các điều kiện đặc biệt". Khi một hàm không thể trả về giá trị có thể sử dụng hoặc một phương thức không thể đáp ứng các điều kiện hậu của nó, hãy ném một ngoại lệ. Không quan trọng tần suất các ngoại lệ này được ném cho đến khi có vấn đề về hiệu suất được chứng minh.

Các ngoại lệ đơn giản hóa mã, bằng cách cho phép tách xử lý lỗi khỏi luồng bình thường. Chỉ cần viết mã đơn giản nhất có thể, và nếu sử dụng try-Catch hoặc ném ngoại lệ dễ dàng hơn, thì hãy làm điều đó.

Các ngoại lệ đơn giản hóa việc kiểm tra bằng cách giảm số lượng đường dẫn thông qua mã. Một hàm không có nhánh sẽ hoàn thành hoặc ném ngoại lệ. Một hàm có nhiều ifcâu lệnh để kiểm tra mã lỗi có nhiều đường dẫn có thể. Rất dễ để có một trong những điều kiện sai hoặc quên hoàn toàn một điều kiện, do đó một số điều kiện lỗi bị bỏ qua.

Công việc gỡ lỗi và bảo trì rất khó khăn khi luồng điều khiển được thực hiện bằng các ngoại lệ.

Về cơ bản, các trường hợp ngoại lệ được thiết kế để trở thành một cơ chế thay đổi luồng điều khiển thông thường của chương trình của bạn - thực hiện các hoạt động bất thường, gây ra tác dụng phụ bất thường, như một cách để thoát khỏi một ràng buộc đặc biệt chặt chẽ mà không thể xử lý ít phức tạp hơn có nghĩa. Ngoại lệ là đặc biệt. Điều này có nghĩa là, tùy thuộc vào môi trường cụ thể mà bạn đang làm việc, việc sử dụng ngoại lệ cho luồng kiểm soát thường xuyên có thể gây ra:

• Không hiệu quả Các vòng lặp bổ sung mà môi trường phải nhảy qua để thực hiện một cách an toàn các thay đổi bối cảnh tương đối khó khăn cần thiết cho các ngoại lệ đòi hỏi phải có dụng cụ và tài nguyên.

• Khó khăn gỡ lỗi Đôi khi thông tin hữu ích (khi cố gắng gỡ lỗi chương trình) thông tin bị ném ra ngoài cửa sổ khi có ngoại lệ xảy ra. Bạn có thể mất dấu vết của trạng thái chương trình hoặc lịch sử có liên quan để hiểu hành vi thời gian chạy

• Vấn đề bảo trì Lưu lượng thực thi khó theo dõi qua các bước nhảy ngoại lệ. Ngoài ra, một ngoại lệ có thể bị ném từ bên trong mã loại hộp đen, có thể không hoạt động theo những cách dễ hiểu khi ném ngoại lệ.

• Các quyết định thiết kế kém Các chương trình được xây dựng theo cách này khuyến khích một khung suy nghĩ, trong hầu hết các trường hợp, không dễ dàng ánh xạ để giải quyết vấn đề một cách thanh lịch. Sự phức tạp của chương trình cuối cùng không khuyến khích lập trình viên hiểu được việc thực hiện đầy đủ và khuyến khích đưa ra các quyết định dẫn đến cải tiến ngắn hạn với chi phí dài hạn cao.

Tôi đã thấy mô hình này được sử dụng nhiều lần.

Có 2 vấn đề lớn:

• Nó cực kỳ tốn kém (khởi tạo đối tượng ngoại lệ, thu thập ngăn xếp cuộc gọi, v.v.). Một số trình biên dịch thực sự có thể có thể tối ưu hóa nó đi, nhưng tôi sẽ không tính đến điều đó trong trường hợp này, vì các trường hợp ngoại lệ không dành cho việc sử dụng đó, do đó bạn không thể mong đợi mọi người tối ưu hóa cho nó.
• Sử dụng ngoại lệ cho luồng điều khiển trong thực tế là một bước nhảy, giống như a goto. Nhảy được coi là có hại, vì một số lý do. Chúng nên được sử dụng, nếu tất cả các lựa chọn thay thế có nhược điểm đáng kể. Trong thực tế, trong tất cả các mã của tôi, tôi chỉ nhớ lại 2 trường hợp, trong đó nhảy rõ ràng là giải pháp tốt nhất.

Đôi khi ngoại lệ là nhanh nhất. Tôi đã thấy các trường hợp ngoại lệ đối tượng null nhanh hơn ngay cả trong Java so với việc sử dụng các cấu trúc điều khiển (tôi không thể trích dẫn nghiên cứu tại thời điểm này, vì vậy bạn sẽ phải tin tưởng tôi). Vấn đề xuất hiện khi Java phải thực sự dành thời gian và điền vào dấu vết ngăn xếp của một lớp ngoại lệ tùy chỉnh thay vì sử dụng các lớp gốc (dường như được lưu trữ ít nhất một phần). Trước khi nói rằng một cái gì đó đơn phương nhanh hơn hoặc chậm hơn, nó sẽ là tốt để điểm chuẩn.

Trong Python, nó không chỉ nhanh hơn mà còn đúng hơn khi làm điều gì đó có thể gây ra ngoại lệ và sau đó xử lý lỗi. Vâng, bạn có thể thực thi một hệ thống loại, nhưng điều đó đi ngược lại triết lý của ngôn ngữ - thay vào đó bạn chỉ cần cố gắng gọi phương thức và bắt kết quả! (Kiểm tra xem một tệp có thể ghi được tương tự hay không - chỉ cần thử ghi vào tệp và bắt lỗi).

Tôi đã thấy nhiều lần nhanh hơn khi làm điều gì đó ngu ngốc như các bảng truy vấn không có ở đó hơn là tìm hiểu xem một bảng có tồn tại trong PHP + MySQL hay không ( câu hỏi mà tôi đánh giá đây thực sự là câu trả lời được chấp nhận duy nhất của tôi với phiếu bầu tiêu cực) .

Tất cả những gì đã nói, việc sử dụng các ngoại lệ nên được giới hạn vì một số lý do:

1. Tình cờ nuốt phải ngoại lệ lồng nhau. Đây là chính. Nếu bạn bắt gặp một số ngoại lệ lồng nhau sâu sắc mà người khác đang cố gắng xử lý, bạn vừa bắn người lập trình viên đồng nghiệp của mình (thậm chí là bạn!) Vào chân.
2. Các xét nghiệm trở nên không rõ ràng. Một khối mã có ngoại lệ trong đó có thể có một trong những điều sai với nó. Mặt khác, một boolean, về mặt lý thuyết có thể gây khó chịu khi gỡ lỗi, nhưng nhìn chung thì không. Điều này đặc biệt đúng khi các try...catchtín đồ dòng điều khiển nói chung (theo kinh nghiệm của tôi) không tuân theo triết lý "tối thiểu hóa mã trong khối thử".
3. Nó không cho phép một else ifkhối. Đủ nói (và nếu ai đó phản đối "Nhưng họ có thể sử dụng các lớp ngoại lệ khác nhau", câu trả lời của tôi là "Đi đến phòng của bạn và không đi ra ngoài cho đến khi bạn nghĩ về những gì bạn đã nói.")
4. Đó là sai ngữ pháp. Exception, với phần còn lại của thế giới (như không tuân thủ try...catchtriết lý dòng chảy kiểm soát), có nghĩa là một cái gì đó đã đi vào trạng thái không ổn định (mặc dù có thể phục hồi). Các trạng thái không ổn định là BAD và nó sẽ giữ tất cả chúng ta vào ban đêm nếu chúng ta thực sự có những ngoại lệ có thể tránh được (nó thực sự làm tôi khó chịu, không nói dối).
5. Nó không phù hợp với phong cách mã hóa phổ biến. Công việc của chúng tôi, cả với mã của chúng tôi và với UI của chúng tôi là làm cho thế giới rõ ràng nhất có thể. try...catchkiểm soát dòng chảy đi ngược lại với những gì thường được coi là thực tiễn tốt nhất. Điều này có nghĩa là phải mất nhiều thời gian hơn cho người mới tham gia dự án để tìm hiểu dự án, điều đó có nghĩa là sự gia tăng số giờ làm việc hoàn toàn không có lợi.
6. Điều này thường dẫn đến sao chép mã. Cuối cùng, các khối, mặc dù điều này không thực sự cần thiết, cần phải giải quyết tất cả các con trỏ lơ lửng bị bỏ ngỏ bởi khối thử bị gián đoạn. Vì vậy, hãy thử khối. Điều này có nghĩa là bạn có thể có một try{ obj.openSomething(); /*something which causes exception*/ obj.doStuff(); obj.closeSomething();}catch(Exception e){obj.closeSomething();}. Trong một if...elsekịch bản truyền thống hơn, closeSomething()ít có khả năng (một lần nữa, kinh nghiệm cá nhân) là một công việc sao chép và dán. (Phải thừa nhận rằng, lập luận cụ thể này có liên quan nhiều đến những người tôi đã gặp hơn là chính triết lý thực tế).

Đối số chính của tôi là việc sử dụng try / Catch cho logic sẽ phá vỡ luồng logic. Theo "logic" thông qua các cấu trúc phi logic là (đối với tôi) phản trực giác và khó hiểu. Tôi đã quen đọc logic của mình là "nếu Điều kiện thì A khác B". Đọc cùng một câu như "Thử A bắt rồi thực hiện B" cảm thấy kỳ lạ. Sẽ còn kỳ quặc hơn nữa nếu câu lệnh Alà một phép gán đơn giản, yêu cầu mã bổ sung để buộc một ngoại lệ nếu conditionlà sai (và làm như vậy có thể sẽ yêu cầu một phân tầng ifnào đó).

Chà, chỉ là vấn đề về nghi thức, trước khi "bắt đầu tranh luận với họ", như bạn nói, tôi sẽ vui lòng hỏi "Tại sao họ sử dụng xử lý ngoại lệ ở tất cả những nơi khác nhau này?"

Ý tôi là, có một số khả năng:

1. họ bất tài
2. có một lý do hoàn toàn hợp lệ cho những gì họ đã làm, có thể không xuất hiện từ cái nhìn đầu tiên.
3. đôi khi nó là một câu hỏi về hương vị và có thể đơn giản hóa một số dòng chương trình phức tạp.
4. Đó là một di tích của quá khứ chưa ai thay đổi và họ sẽ rất vui nếu ai đó làm điều đó

... Tôi nghĩ tất cả những thứ này đều có khả năng như nhau. Vì vậy, chỉ cần hỏi họ độc đáo.

Hãy thử Catch chỉ nên được sử dụng để xử lý ngoại lệ. Hơn nữa, xử lý ngoại lệ đặc biệt. Thử bắt của bạn chỉ nên bắt ngoại lệ dự kiến, khôn ngoan khác nó không được hình thành tốt. Nếu bạn cần sử dụng một lần bắt tất cả hãy thử bắt, thì có lẽ bạn đang làm sai điều gì đó.

CHỈNH SỬA:

Lý do: Bạn có thể lập luận rằng nếu bạn sử dụng thử bắt như một toán tử có điều kiện, Làm thế nào bạn sẽ tính đến các ngoại lệ THỰC SỰ?

Ngoại lệ là khi điều đặc biệt xảy ra. Là chương trình hoạt động theo quy trình công việc thường xuyên đặc biệt?

Lý do sử dụng ngoại lệ:

1. Nếu bạn quên bắt gặp một tình huống đặc biệt, chương trình của bạn sẽ chết và dấu vết ngăn xếp sẽ cho bạn biết chính xác lý do tại sao. Nếu bạn quên xử lý giá trị trả về cho một trường hợp ngoại lệ, sẽ không cho biết chương trình của bạn sẽ thể hiện hành vi không chính xác bao xa.
2. Sử dụng giá trị trả về chỉ hoạt động nếu có giá trị sentinel bạn có thể trả về. Nếu tất cả các giá trị trả về có thể đã hợp lệ, bạn sẽ làm gì?
3. Một ngoại lệ sẽ mang thêm thông tin về những gì đã xảy ra có thể hữu ích.

Lý do không sử dụng ngoại lệ:

1. Nhiều ngôn ngữ không được thiết kế để làm cho ngoại lệ nhanh chóng.
2. Các ngoại lệ di chuyển nhiều lớp lên ngăn xếp có thể để lại trạng thái không nhất quán trong trạng thái của chúng

Đến cuối cùng:

Mục tiêu là viết mã truyền đạt những gì đang diễn ra. Các ngoại lệ có thể giúp / cản trở tùy thuộc vào những gì mã đang làm. Thử / bắt trong python cho KeyError trên tham chiếu từ điển là hoàn toàn (miễn là bạn biết ngôn ngữ) thử / bắt cho cùng một lớp chức năng KeyError năm lớp là nguy hiểm.

Tôi sử dụng try-> Catch như điều khiển luồng trong các tình huống nhất định. Nếu logic chính của bạn phụ thuộc vào điều gì đó không thành công, nhưng bạn không muốn ném ngoại lệ và thoát ... Đó là những gì một khối thử-> bắt dành cho. Tôi viết rất nhiều tập lệnh unix phía máy chủ không được giám sát, và điều quan trọng hơn nhiều đối với họ là không thất bại, hơn là để họ thất bại một cách đáng yêu.

Vì vậy, hãy thử Kế hoạch A và nếu Kế hoạch A chết, hãy bắt và chạy với Kế hoạch B ... Và nếu kế hoạch B thất bại, cuối cùng hãy sử dụng để khởi động Kế hoạch C, điều này sẽ khắc phục một trong các dịch vụ bị lỗi trong A hoặc B hoặc trang tôi.

Nó phụ thuộc vào ngôn ngữ và có thể vào việc thực hiện đang được sử dụng. Tiêu chuẩn trong C ++ là các ngoại lệ nên được lưu cho các sự kiện thực sự đặc biệt. Mặt khác, trong Python, một trong những hướng dẫn là " dễ xin tha thứ hơn là cho phép ", vì vậy việc tích hợp các khối thử / ngoại trừ trong logic chương trình được khuyến khích.

Đó là một thói quen xấu, nhưng thỉnh thoảng tôi vẫn làm điều đó với trăn. Giống như thay vì kiểm tra xem một tập tin tồn tại tôi chỉ cần thử và xóa nó. Nếu nó ném một ngoại lệ, tôi bắt và chỉ cần biết rằng nó không ở đó. <== (không nhất thiết đúng nếu người dùng khác sở hữu tệp, nhưng tôi thực hiện nó trong thư mục chính của người dùng để điều này KHÔNG xảy ra).

Tuy nhiên, lạm dụng nó là một thực hành xấu.

Tôi thích cách Apple định nghĩa nó: Ngoại lệ chỉ dành cho lỗi lập trình viên và lỗi thời gian chạy nghiêm trọng. Khác sử dụng mã lỗi. Nó giúp tôi quyết định khi nào nên sử dụng nó, tự nghĩ "Đây có phải là lỗi của lập trình viên không?"

Điều này nghe có vẻ như sử dụng xử lý ngoại lệ để xây dựng logic goto trên đầu ngôn ngữ không có lệnh goto.

Vì nhiều lý do tại sao logic goto là xấu, bạn có thể tham khảo câu hỏi này: https://stackoverflow.com/questions/46586/goto-still-considered-harmful