Tại sao tôi nên viết tất cả các Tuyên bố trong Thử-Bắt?

Người đứng đầu công ty của tôi nói rằng tôi phải viết tất cả, tức là TẤT CẢ mã của tôi trong các câu lệnh Thử bắt. Bây giờ, tôi có thể hiểu cách tiếp cận 'tốt hơn là an toàn hơn xin lỗi' ở đây, nhưng không quá đau lòng khi nghĩ rằng sẽ có một ngoại lệ khi Nhãn được tạo, vị trí của biểu mẫu được đặt. đã có những trường hợp Ngoại lệ trong các hoạt động đơn giản như vậy.

Người đứng đầu công ty của tôi nói rằng tôi phải viết tất cả, tức là TẤT CẢ mã của tôi trong các câu lệnh Thử bắt.

Vâng, điều này là một chút quá mức và chỉ dẫn đến mã ồn ào. Những lợi ích của việc có tất cả các mã (mỗi phương thức, ví dụ) được viết bằng một trình xử lý bắt thử là gì? Nó chỉ cho bạn biết có một lỗi cần sửa trong hầu hết các trường hợp. Thông thường, ngoại lệ có thể và nên tránh ở nơi đầu tiên.

Một cái nhìn trên dấu vết ngăn xếp hầu hết là đủ để tiết lộ nguyên nhân trong mã của bạn, ngay cả khi phương thức lỗi không tự thực hiện việc bắt. Có những lúc các nhà phát triển tham nhũng dấu vết ngăn xếp trong các trường hợp ngoại lệ, nhưng đó là trường hợp thường xuyên hơn khi bạn có rất nhiều trình xử lý ngoại lệ. Giống như bất cứ điều gì: Một chút là tốt, nhưng quá nhiều trong số đó là chất độc.

Xử lý ngoại lệ thực sự khá đơn giản:

Bắt ngoại lệ

• Bất cứ khi nào bạn cần một hành động đặc biệt như một phản ứng với ngoại lệ
• Bất cứ khi nào một ngoại lệ sẽ rời khỏi chương trình trong trạng thái không nhất quán nếu không được xử lý

Nếu bạn nghĩ về nó, thì hầu như luôn luôn chỉ có một nơi tốt để xử lý một ngoại lệ xảy ra. Và do đó, người xử lý nên ở nơi đó.

Nhiều trường hợp ngoại lệ thậm chí không nên được ném ngay từ đầu, vì vậy đừng xây dựng các cấu trúc kiểm soát của bạn xung quanh việc xử lý ngoại lệ, thay vào đó hãy cố gắng tránh sự xuất hiện của ngoại lệ bất cứ khi nào và bất cứ khi nào có thể.

Hãy nhớ sụp đổ sớm khi mọi thứ đi (không sửa chữa) sai. Đặt tất cả các mã trong các câu lệnh thử là vô lý, nhưng đừng quên báo cáo và ghi lại TẤT CẢ các ngoại lệ.

nhưng không quá tâm huyết khi nghĩ rằng sẽ có một ngoại lệ khi các Nhãn được tạo, vị trí của biểu mẫu được đặt. đã có những trường hợp Ngoại lệ trong các hoạt động đơn giản như vậy.

Hoàn toàn đồng ý! Luôn có một cách để mọi thứ đi sai mà bạn không thấy trước. Và "lòng gà" là một cách diễn đạt vô lý để sử dụng trong bối cảnh này; phát triển phần mềm không phải là để chứng minh mach mach của bạn thông qua việc bỏ qua các vấn đề tiềm ẩn.

Có gì là một câu hỏi hợp lệ là cho dù đó là hữu ích cho trường hợp ngoại lệ được bắt tại điểm mà tiêu chuẩn mã hóa của bạn nói rằng họ phải làm vậy. Câu lệnh của bạn đọc giống như bạn phải có khối thử / bắt xung quanh mọi thân phương thức và điều đó thực sự vô lý vì bạn thường không thể ngay lập tức làm điều gì đó hữu ích với một ngoại lệ, và đó thực sự là toàn bộ ngoại lệ: bạn có thể chọn để cho phép chúng tuyên truyền ngăn xếp cuộc gọi sẽ được xử lý tại điểm thích hợp.

Tôi sẽ biến điều này theo cách khác. Vâng, như một xử lý ngoại lệ quy tắc chung là một điều tốt, nhưng bạn thực sự có thể xử lý mọi ngoại lệ có thể theo cách hợp lý tại điểm mà nó bị bắt không? Đôi khi, đặc biệt là nếu bạn không viết phần mềm nhiệm vụ quan trọng, nó là tốt hơn để chỉ đơn giản là sụp đổ và đốt cháy trong một số cách nửa chiều kiểm soát khi mọi thứ đi sai lầm khủng khiếp.

Nếu bạn không thể chắc chắn 100% rằng bạn có thể xử lý mọi ngoại lệ duy nhất có thể bị bắt, thì có lẽ tốt hơn hết bạn nên viết một số trình xử lý ngoại lệ chung, bao bọc vòng lặp chính của chương trình - cơ chế chính xác về cách thực hiện điều đó rõ ràng phụ thuộc vào những gì ngôn ngữ mà bạn đang làm việc tại đây, đăng nhập càng nhiều chi tiết về ngoại lệ như bạn có thể, tiết kiệm nhà nước chương trình (ở đâu đó. khác hơn là bất kỳ dữ liệu lưu trữ cho người dùng hiện đang làm việc chống lại - hãy nhớ rằng, nó có thể tất cả các bị hỏng vào thời điểm này ), và như thế. Sau đó, suy nghĩ lại ngoại lệ và để HĐH xử lý nó theo cách phù hợp. Trong trình xử lý ngoại lệ bắt tất cả này, hãy chuẩn bị cho thất bại thảm khốc. Sau đó, khi chương trình được khởi động lại, hãy xem liệu trạng thái này có hữu ích không, và khôi phục lại những gì có thể được cứu vãn nếu có; và có thể đề nghị người dùng gửi báo cáo lỗi lại cho bạn.

Nhìn chung, việc sử dụng thử / bắt mà phần lớn không được dùng nữa, bởi vì khối bắt quá đắt từ điểm tài nguyên. Sử dụng thử / bắt nhắc nhở tôi về quản lý rủi ro . Quản lý rủi ro có hai khía cạnh:

1. Xác suất rủi ro xảy ra
2. Những thiệt hại nó có thể có

Bây giờ, nếu bạn đi ra khỏi nhà, một cây đàn piano rơi xuống đầu bạn ở đâu đó trong khi rất khó xảy ra (có thể là 0,001%), nhưng có thể giết chết bạn.

Xử lý ngoại lệ là như thế. Thử khối không đắt. Nhưng khối bắt thực sự tốn kém, bởi vì nó cần tạo một bảng theo dõi ngăn xếp và làm các công việc khác. Do đó, khi đưa ra quyết định về khối thử / bắt, bạn nên xem xét số lần bạn có thể nhấn khối bắt. Nếu trong số 10.000 lần sử dụng, bạn chỉ đánh nó 1 lần, sau đó sử dụng nó. Nhưng nếu đó là một hình thức và người dùng có thể không điền chính xác 50% lần, thì bạn nên tránh đưa khối thử / bắt vào hoạt động ở đó.

Ở những nơi có xác suất xảy ra ngoại lệ cao, nên sử dụng if {} else {}các khối để tránh xảy ra ngoại lệ. Ví dụ: nơi bạn muốn chia hai số, thay vì viết:

try
{
    int result = a/b;
}
catch (DivisionByZeroException ex)
{
    // Showing a message here, and logging of course.
}

bạn nên viết:

if (b == 0)
{
    int result = a/b;
}
else
{
    // Showing a message to user to change the value of b, etc.
}

Bạn nên sử dụng thử bắt khi thích hợp, nhưng xin vui lòng đừng bắt tất cả các ngoại lệ và thậm chí không đăng nhập nó. Tại thời điểm đó, mã mùi và công việc kém chất lượng.

Cá nhân tôi không thể chịu được ngoại lệ, họ RẤT, RẤT, RẤT khó xử lý chính xác. Và cố gắng để xóa dữ liệu tham nhũng là RẤT, RẤT, RẤT khó!

http://bloss.msdn.com/b/mgrier/archive/2004/02/18/75324.aspx

http://bloss.msdn.com/b/oldnewthing/archive/2004/04/22/118161.aspx

http://bloss.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx

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

Nếu bạn không gọi mọi chức năng như:

try
{
    TrivialFunction();
}
catch(TypeAException)
{
    //MaybeFix
}
catch(TypeBException)
{
    //MaybeFix
}
catch(TypeCException)
{
    //NO FIX - CORRUPT DATA
}
catch(TypeDException)
{
    //NO FIX - UNKNOWN STATE
}
catch(OutOfMemoryException)
{
    //Try to fix this one! Destructors might allocate on their own ;)
}
catch(Exception)
{
    //Nothing to see here, move on, everything is OK ;)
}

Không có cách nào bạn sẽ dọn sạch chính xác trên mỗi điểm thoát. Ngoại lệ là CỨNG!

Điều tốt duy nhất về các trường hợp ngoại lệ là nếu bạn không bắt được chúng, ứng dụng sẽ gặp sự cố.