2012-07-03 25 views
6

Trong hầu hết các trường hợp, có thể bắt ngoại lệ trong Java, thậm chí là các ngoại lệ không được kiểm soát. Tuy nhiên, nó không nhất thiết phải làm một cái gì đó về nó (ví dụ như trong bộ nhớ).Khi nào thì một ứng dụng sẽ gặp sự cố do ngoại lệ trong Java (vấn đề thiết kế)?

Đối với các trường hợp khác, vấn đề tôi đang cố giải quyết là nguyên tắc thiết kế. Tôi đang cố gắng thiết lập một nguyên tắc thiết kế hoặc một bộ quy tắc cho biết khi nào người ta nên từ bỏ một tình huống đặc biệt, ngay cả khi nó được phát hiện kịp thời. Mục tiêu đang cố gắng không làm hỏng ứng dụng càng nhiều càng tốt.

Có ai đó đã suy nghĩ và truyền đạt về điều này không? Tôi đang tìm kiếm các trường hợp cụ thể chung và các giải pháp có thể, hoặc quy tắc ngón tay cái.

CẬP NHẬT

Gợi ý cho đến nay:

  • Ngừng chạy nếu sự liên lạc dữ liệu có thể bị tổn hại
  • Ngừng chạy nếu dữ liệu có thể bị xóa
  • Ngừng chạy nếu bạn không thể làm bất cứ điều gì về nó (hết bộ nhớ ...)
  • Dừng chạy nếu dịch vụ chính không khả dụng hoặc beco mes không có sẵn và không thể được khởi động lại

  • Một phương pháp/dịch vụ nên kiểm tra xem nó có thể thực hiện nhiệm vụ của mình từ một trạng thái ổn định, nếu không nó sẽ thông báo cho người sử dụng (đăng nhập) và không làm gì cả

  • Nếu ứng dụng phải được dừng lại , làm suy giảm như một cách duyên dáng càng tốt
  • sử dụng rollbacks trong các giao dịch db
  • ngoại lệ tùy chỉnh có thể được sử dụng để đưa ra lời khuyên về làm thế nào để giải quyết tình hình bằng cách xử lý
  • Đăng thông tin càng nhiều có liên quan như bạn có thể
  • Thông báo cho các nhà phát triển
  • Preserve nhà nước và sự liên lạc dữ liệu càng nhiều càng tốt, bạn có thể

  • Sửa nhanh có thể gây hại, khi gỡ lỗi, chúng ta hãy rõ hơn về vụ tai nạn ứng dụng và phân tích chi tiết những gì gây ra nó

+2

Nếu ứng dụng của bạn là quan trọng (ví dụ máy chủ thí điểm một nhà máy) ứng dụng của bạn phải 1) điện thoại cho người sẽ phải sửa chữa nó 2) chạy miễn là nó chắc chắn không xóa tất cả mọi thứ (dữ liệu mạch lạc gần như không bao giờ có thể được bị xâm phạm). –

+3

Lý tưởng nhất là ứng dụng của bạn sẽ không bao giờ gặp sự cố. Tuy nhiên, ứng dụng của bạn sẽ thất bại một cách duyên dáng khi một thành phần như cơ sở dữ liệu hoặc máy ảnh bị thiếu hoặc không thể truy cập được. –

+0

Tôi đã nghĩ rằng, đối với rất nhiều RuntimeExceptions nghiêm trọng, bạn sẽ không có bất kỳ sự lựa chọn nào về việc liệu bạn có cho phép nó sụp đổ hay không, trừ khi bạn quấn bit mở mã trong khối try ... catch. –

Trả lời

1

Tại sao và khi nào để xảy ra sự cố ứng dụng không có quy tắc cụ thể nào ...... Tôi cho phép ứng dụng của tôi gặp sự cố sau đây:

1. Sửa lỗi nhanh có thể khởi động lại và được poten tially nguy hiểm. Tôi KHÔNG cảm thấy nó thích hợp để sửa lỗi, mà không biết lý do thực sự cho sự cố mã của tôi là gì. Việc cho phép ứng dụng gặp sự cố dẫn tôi đến lỗi trong mã của tôi.

2. Cho phép lỗi mã giúp tôi hiểu ngôn ngữ lập trình và lỗi logic tốt hơn.

Đó là lý do của tôi để cho phép sự cố ứng dụng ..

2

Những người tạo Java và.Net đã quyết định sử dụng TYPE của một đối tượng ngoại lệ được ném để xác định khi nào nó bị bắt và khi nào nó được xem là đã được giải quyết, một quyết định thiết kế có thể được thúc đẩy bởi cách C++ xử lý các ngoại lệ. Mặc dù xử lý ngoại lệ C++ là nhiều cải tiến so với những gì tồn tại trước đây, việc sử dụng kiểu đối tượng ngoại lệ làm phương tiện chính để xác định ngoại lệ nào đã bị bắt chứ không phải là một trong những tính năng tốt hơn của nó.

Vì bắt ngoại lệ được kiểm soát theo loại ngoại lệ, không có phương tiện chuẩn cho ngoại lệ để cho biết liệu thao tác thất bại có thay đổi trạng thái của bất kỳ đối tượng nào trong hệ thống hay không. (trái ngược với một trạng thái mà, trong khi nó có thể được bất ngờ bởi người gọi và không tương thích với các tham số được thông qua, nếu không sẽ được xem xét bởi các phương pháp được gọi là hoàn toàn hợp pháp). Trong nhiều trường hợp, nếu đáp ứng yêu cầu của người dùng, hệ thống sẽ gọi phương thức cố gắng thực hiện điều gì đó và không thể, nhưng phương pháp này không ảnh hưởng xấu đến trạng thái của bất kỳ đối tượng nào và vấn đề không phải do đối tượng có trạng thái bị hỏng, thường có thể tốt nhất là chỉ cần thông báo cho người dùng rằng hành động được yêu cầu không thể được thực hiện và tiếp tục. Thật không may, không có cách nào để phân biệt ngoại lệ 'vô hại' của các loại được chỉ ra ở trên, từ những trường hợp chỉ ra các vấn đề nghiêm trọng trên toàn hệ thống. Mặc dù 99% ngoại lệ có thể sẽ tương đối vô hại, một phần nhỏ sẽ do các điều kiện có thể gây tham nhũng cho các tài liệu mở. Nếu một tài liệu mở đã bị hỏng, nó có thể là tốt hơn cho một chương trình ngay lập tức sụp đổ hoàn toàn hơn để cho nó thay thế một bản sao tốt trên đĩa với một bị hỏng.

Nếu ném ngoại lệ tùy chỉnh, có thể bao gồm các thuộc tính trong loại ngoại lệ sẽ cho phép mã để quyết định một cách hữu ích hơn nên làm gì về ngoại lệ. Thật không may, nhiều trường hợp ngoại lệ bị ném, dù vô hại hay không, sẽ không bao gồm các thuộc tính như vậy.

1

Việc bẻ khóa ứng dụng là cái gì đó phụ thuộc vào mức độ quan trọng của ứng dụng và kiến ​​trúc triển khai.

Ví dụ, ứng dụng sẽ không sụp đổ nếu nó điều khiển tên lửa từ trái đất (ngoại trừ trường hợp không thể kiểm soát và ưu tiên dữ liệu).

Khi ứng dụng được thiết kế, bạn nên thiết kế chúng để không có dữ liệu nào trong kho dữ liệu bị xóa hoặc thay đổi.

Kết luận không có cách nào để thoát xuống các quy tắc khi ứng dụng gặp sự cố.

Các vấn đề liên quan