Tại sao Catch (Ngoại lệ) hầu như luôn là một ý tưởng tồi?

Question

Tại sao catch(Exception) hầu như luôn là một ý tưởng tồi?

Answer 1

Vì khi bạn bắt ngoại lệ , bạn phải xử lý đúng cách. Và bạn không thể mong đợi để xử lý tất cả các loại ngoại lệ trong mã của bạn. Ngoài ra khi bạn bắt tất cả các ngoại lệ, bạn có thể nhận được một ngoại lệ mà không thể xử lý và ngăn chặn mã ở trên trong ngăn xếp để xử lý nó đúng cách.

Hiệu trưởng chung là nắm bắt loại cụ thể nhất mà bạn có thể.

Answer 2

Vì bạn không thực sự biết tại sao ngoại lệ xảy ra và một số trường hợp ngoại lệ yêu cầu xe rất đặc biệt phải được xử lý chính xác (nếu có thể), chẳng hạn như ngoại lệ OutOfMemoryException và ngoại lệ tương tự ở mức thấp.

Vì vậy, bạn chỉ nên bắt ngoại lệ:

• mà bạn biết chính xác làm thế nào để đối phó với nó (ví dụ FileNotFoundException hoặc lâu hơn)
• khi bạn sẽ lại tăng chúng sau đó (ví dụ để thực hiện bài -fail cleanup)
• khi bạn cần chuyển ngoại lệ sang một chủ đề khác

Answer 3

Tùy thuộc vào những gì bạn cần. Nếu bạn cần xử lý các loại ngoại lệ khác nhau theo nhiều cách khác nhau thì bạn nên sử dụng nhiều khối catch và nắm bắt được nhiều ngoại lệ cụ thể nhất có thể.

Nhưng đôi khi bạn có thể cần xử lý tất cả các ngoại lệ theo cùng một cách. Trong trường hợp như vậy bắt (Ngoại lệ) có thể là ok. Ví dụ:

try 
    { 
     DoSomething(); 
    } 
    catch (Exception e) 
    { 
     LogError(e); 
     ShowErrorMessage(e); // Show "unexpected error ocurred" error message for user. 
    } 

Answer 4

Bạn chỉ nên bắt ngoại lệ nếu bạn có thể xử lý chúng đúng cách. Vì bạn không thể xử lý đúng tất cả ngoại lệ có thể, bạn không nên bắt chúng :-)

Answer 5

Câu chuyện ngắn: nó được gọi là đắp mặt nạ lỗi. Nếu bạn có một đoạn mã không hoạt động tốt và loại bỏ các ngoại lệ (hoặc bạn truyền đầu vào không đúng định dạng cho đoạn mã đó) và bạn chỉ mù mắt bằng cách bắt tất cả các ngoại lệ có thể xảy ra, bạn thực sự sẽ không bao giờ phát hiện lỗi và khắc phục lỗi đó.

Answer 6

Đây có thể là java cụ thể:

Đôi khi bạn sẽ cần phải gọi các phương thức ném ngoại lệ đã kiểm tra. Nếu điều này nằm trong lớp EJB/business logic của bạn, bạn có 2 lựa chọn - bắt chúng hoặc ném lại chúng.

Bắt các lớp ngoại lệ cụ thể có nghĩa là bạn sẽ cần phải phân tích lại hành động của mình để có thể ném ngoại lệ nào khi bạn xem cách mã này xử lý ngoại lệ. Bạn thường sẽ nhận được vào một "nếu ..." tình hình và nó có thể được rất nhiều nỗ lực chỉ cần làm việc ra nếu trường hợp ngoại lệ được xử lý một cách chính xác.

Tái ném có nghĩa là mã gọi EJB của bạn sẽ được rải rác bằng mã đánh bắt thông thường sẽ không có ý nghĩa gì đối với lớp gọi điện. n.b. ném ngoại lệ đã kiểm tra từ các phương thức EJB sẽ có nghĩa là bạn chịu trách nhiệm tự động quay lại bất kỳ giao dịch nào.

Answer 7

Bên cạnh những gì chưa được trả lời bởi @anthares:

Bởi vì khi bạn bắt ngoại lệ bạn đang phải xử lý nó đúng. Và bạn không thể mong đợi để xử lý tất cả các loại ngoại lệ trong mã của bạn. Ngoài ra khi bạn bắt tất cả các ngoại lệ, bạn có thể nhận được một ngoại lệ mà không thể xử lý và ngăn chặn mã ở trên trong ngăn xếp để xử lý nó đúng cách.

Hiệu trưởng chung là nắm bắt loại cụ thể nhất mà bạn có thể.

catch(Exception) là thực tiễn không tốt vì nó cũng nắm bắt tất cả RuntimeException (ngoại lệ không được kiểm soát).

Answer 8

Nhưng đôi khi cũng được! Giống như nếu bạn có một đoạn mã làm điều gì đó 'thêm', điều bạn thực sự không quan tâm, và bạn không muốn nó làm nổ tung ứng dụng của bạn. Ví dụ, tôi đã làm việc trên một ứng dụng lớn gần đây, nơi các đối tác kinh doanh của chúng tôi muốn một giao dịch hàng ngày nhất định được tóm tắt trong một tệp nhật ký mới. Họ giải thích rằng nhật ký không quan trọng đối với họ, và nó không đủ tiêu chuẩn như một yêu cầu. Nó chỉ là một cái gì đó thêm mà sẽ giúp họ làm cho tinh thần của dữ liệu được xử lý. Họ không cần nó, bởi vì họ có thể lấy thông tin ở nơi khác. Vì vậy, đó là một trường hợp hiếm hoi mà nó là hoàn toàn tốt để bắt và nuốt ngoại lệ.

Tôi cũng đã làm việc tại một công ty nơi tất cả các Throwables đã bị bắt, và sau đó được sửa lại bên trong một RuntimeException tùy chỉnh. Tôi sẽ không khuyên bạn nên cách tiếp cận này, nhưng chỉ ra rằng nó được thực hiện.

Answer 9

Tôi tìm thấy hai sử dụng có thể chấp nhận bắt (Ngoại lệ): - Ở cấp cao nhất của ứng dụng (ngay trước khi trở về người dùng). Bằng cách đó bạn có thể cung cấp một thông điệp đầy đủ. - Sử dụng nó để che giấu ngoại lệ cấp thấp cho một doanh nghiệp.

Trường hợp đầu tiên là tự explanative, nhưng hãy để tôi phát triển thứ hai:

Làm:

try { 
    xxxx 
} catch(Exception e) { 
    logger.error("Error XXX",e) 
} 

là lỗi mặt nạ như @dimitarvp nói.

Nhưng

try { 
    xxxx 
} catch(Exception e) { 
    throw new BussinessException("Error doing operation XXX",e) 
} 

Đó là một điều khác nhau. Bằng cách đó bạn không bỏ qua lỗi và ẩn dưới thảm. Bạn đang cung cấp một ngoại lệ cấp cao với một thông điệp giải thích hơn cho các lớp ứng dụng cao hơn.

Điều quan trọng là cả hai quản lý ngoại lệ ở lớp chính xác của nó. Nếu bạn cho phép leo thang một ngoại lệ cấp thấp lên một tầng kinh doanh cao thì thực tế là lớp cao hơn có thể quản lý nó tốt. Trong trường hợp đó, tôi thích che giấu các ngoại lệ cấp thấp với một doanh nghiệp cung cấp ngữ cảnh và thông điệp tốt hơn và nó cũng có ngoại lệ ban đầu để có thể đi đến chi tiết.

Mặc dù vậy, nếu bạn có thể nắm bắt nhiều ngoại lệ cụ thể hơn và bạn có thể cung cấp điều trị tốt hơn cho họ, bạn phải làm điều đó.

Nếu trong một khối mã, bạn có thể nhận được SQLException và NetworkException, bạn phải nắm bắt chúng và cung cấp đầy đủ các thông điệp và điều trị cho mỗi người trong số họ. Nhưng nếu ở cuối khối try/catch bạn có một ngoại lệ ánh xạ nó với một BussinessException nó ok cho tôi. Trong thực tế, tôi thấy đầy đủ rằng các lớp dịch vụ cao hơn chỉ ném ngoại lệ kinh doanh (với các chi tiết bên trong).