Các ngoại lệ làm cho nó thực sự dễ dàng để viết mã trong đó một ngoại lệ được ném ra sẽ phá vỡ các bất biến và để các đối tượng ở trạng thái không nhất quán. Về cơ bản, chúng buộc bạn phải nhớ rằng hầu hết mọi tuyên bố bạn đưa ra đều có khả năng bị ném và xử lý điều đó một cách chính xác. Làm như vậy có thể phức tạp và phản trực giác.
Hãy coi một cái gì đó như thế này như một ví dụ đơn giản:
class Frobber
{
int m_NumberOfFrobs;
FrobManager m_FrobManager;
public:
void Frob()
{
m_NumberOfFrobs++;
m_FrobManager.HandleFrob(new FrobObject());
}
};
Giả sử ý FrobManagerchí deletelà FrobObject, điều này có vẻ ổn, phải không? Hoặc có thể không ... Hãy tưởng tượng sau đó nếu một trong hai FrobManager::HandleFrob()hoặc operator newném một ngoại lệ. Trong ví dụ này, số gia tăng của m_NumberOfFrobskhông được quay trở lại. Do đó, bất kỳ ai sử dụng phiên bản này của Frobbersẽ có một đối tượng có thể bị hỏng.
Ví dụ này có vẻ ngu ngốc (được rồi, tôi đã phải căng mình một chút để tạo ra một cái :-)), nhưng, điểm rút ra là nếu một lập trình viên không liên tục nghĩ đến các ngoại lệ và đảm bảo rằng mọi hoán vị của trạng thái đều được cuộn quay lại bất cứ khi nào có ném, bạn sẽ gặp rắc rối theo cách này.
Ví dụ, bạn có thể nghĩ về nó giống như bạn nghĩ về mutexes. Bên trong phần quan trọng, bạn dựa vào một số câu lệnh để đảm bảo rằng cấu trúc dữ liệu không bị hỏng và các luồng khác không thể nhìn thấy các giá trị trung gian của bạn. Nếu bất kỳ câu nào trong số đó ngẫu nhiên không chạy, bạn sẽ kết thúc với một thế giới đau đớn. Bây giờ loại bỏ các khóa và đồng thời, và suy nghĩ về mỗi phương pháp như vậy. Hãy coi mỗi phương thức như một giao dịch của các hoán vị trên trạng thái đối tượng, nếu bạn muốn. Khi bắt đầu cuộc gọi phương thức của bạn, đối tượng phải ở trạng thái sạch và ở cuối cũng phải có trạng thái sạch. Ở giữa, biếnfoo có thể không nhất quán vớibar, nhưng mã của bạn cuối cùng sẽ khắc phục điều đó. Ngoại lệ có nghĩa là bất kỳ câu lệnh nào của bạn có thể làm gián đoạn bạn bất cứ lúc nào. Tùy thuộc vào bạn trong từng phương pháp riêng lẻ để làm cho nó đúng và quay trở lại khi điều đó xảy ra, hoặc sắp xếp các hoạt động của bạn để việc ném không ảnh hưởng đến trạng thái đối tượng. Nếu bạn hiểu sai (và rất dễ mắc phải lỗi này), thì người gọi sẽ nhìn thấy các giá trị trung gian của bạn.
Các phương thức như RAII, mà các lập trình viên C ++ yêu thích đề cập đến như là giải pháp cuối cùng cho vấn đề này, sẽ đi một chặng đường dài để bảo vệ khỏi điều này. Nhưng chúng không phải là một viên đạn bạc. Nó sẽ đảm bảo rằng bạn giải phóng tài nguyên ngay lập tức, nhưng không giải phóng bạn khỏi việc phải suy nghĩ về sự hỏng hóc của trạng thái đối tượng và người gọi nhìn thấy các giá trị trung gian. Vì vậy, đối với nhiều người, nói dễ dàng hơn, theo định nghĩa của phong cách mã hóa, không có ngoại lệ . Nếu bạn hạn chế loại mã bạn viết, thì việc giới thiệu những lỗi này sẽ khó hơn. Nếu không, bạn rất dễ mắc sai lầm.
Toàn bộ sách đã được viết về mã hóa an toàn ngoại lệ trong C ++. Rất nhiều chuyên gia đã hiểu sai. Nếu nó thực sự phức tạp và có quá nhiều sắc thái, có lẽ đó là một dấu hiệu tốt cho thấy bạn cần bỏ qua tính năng đó. :-)