Dịch vụ web có nên ném ngoại lệ HOẶC các đối tượng kết quả

Question

Tôi không chắc mình hoàn toàn hài lòng khi ném ngoại lệ trong các dịch vụ web là một ý tưởng hay. Tôi sẽ không quan tâm nhiều nếu nó không phải là dấu vết ngăn xếp. Đây không phải là điều tôi không thể.

Tôi đã nghiên cứu xung quanh một số triển khai và thực sự dường như không có sự đồng thuận về điều này. CampaignMonitor chẳng hạn trả về một đối tượng Result, nhưng một số khác thì không.

Kiến trúc, tôi không chắc chắn trả về đối tượng trả về có ý nghĩa, chắc chắn ngoại lệ là ngoại lệ, nhưng những gì tôi thích về đối tượng Trả về là giải pháp duyên dáng hơn cho người dùng cuối.

Có ai có giải pháp nào tốt hơn không?

EDIT

BTW Tôi đang sử dụng dịch vụ web ASMX, trong đó việc bật CustomErrors on không phải là một tùy chọn.

Answer 1

Bạn đang nói về dấu vết ngăn xếp nào? Bạn đã thử cái này chưa?

Trong cả hai dịch vụ ASMX và WCF, ngoại lệ không được bắt buộc sẽ được dịch thành lỗi SOAP. Trong cả hai trường hợp, chúng có thể được định cấu hình để không bao gồm bất kỳ dấu vết ngăn xếp nào. Trong thực tế, đó là mặc định trong WCF.

Vì vậy, cách thích hợp để trả về lỗi như thế này là do lỗi. Một cách để tạo ra lỗi là ném và không xử lý một ngoại lệ.

Answer 2

Bạn có thể làm rõ một chút không? Phía máy chủ của một dịch vụ web có thể ném một ngoại lệ. Phía máy chủ của một dịch vụ web có thể trả về một thông báo cho phía máy khách. Thông báo đó có thể chứa thông tin lỗi và thông tin lỗi đó có thể bao gồm chi tiết ngoại lệ cụ thể. Hoặc nó có thể không. Ở phía máy khách, bạn thường có một proxy được tạo để xử lý thư từ máy chủ. Proxy này có thể tạo ra một ngoại lệ nếu đáp ứng đó chứa thông tin lỗi.

Bạn đang phân vân về phần nào của tình huống này?

Answer 3

Tôi cho rằng ném ngoại lệ nói chung là mẫu thiết kế tốt hơn, sau đó trả lại kết quả. Tôi giả sử rằng bạn phải làm là bên trong các dịch vụ web của bạn để ẩn dấu vết ngăn xếp bằng cách áp dụng các mô hình sau đây để mỗi phương pháp tiếp xúc như dịch vụ web:

public void MyWebServiceMethod() {
try
{

///Do something that may cause an error 

} catch(Exception ex)
{ throw new ApplicationException("User friendly descritption of exception");

}

}

hoặc bạn cũng có thể

catch(Exception ex) { throw ex; }

Nếu bạn ném lại một ngoại lệ, bạn sẽ ẩn dấu vết ngăn xếp ban đầu từ các máy khách của các dịch vụ web của bạn.

Answer 4

Đừng để thực tế rằng bạn đang sử dụng dịch vụ web gây nhầm lẫn vấn đề. Đó chỉ là một chi tiết thực hiện.

Sử dụng chiến lược xử lý ngoại lệ thông thường của bạn. Thực hành tốt nhất nói đừng bẫy ngoại lệ trong mã cấp thấp - trừ khi bạn có thể giải quyết ngoại lệ đó và tiếp tục bình thường. Các ngoại lệ nên được nâng lên lớp trình bày để người dùng có thể được thông báo về lỗi.

Vì vậy, như được áp dụng cho dịch vụ web - nói chung ném ngoại lệ (dẫn đến SoapFault). Điều này cho phép mã máy khách gọi để sử dụng nó được xây dựng trong tiêu chuẩn xử lý ngoại lệ để xử lý nó.

Answer 5

một cách tiếp cận là tách các lỗi hệ thống và doanh nghiệp. (Lỗi hệ thống: ví dụ: yêu cầu không đúng định dạng, lỗi kinh doanh do người dùng không được ủy quyền, v.v.; ví dụ: phương pháp UpdateCars dẫn đến lỗi, người dùng không sở hữu bất kỳ ô tô nào).

Trong trường hợp có lỗi kinh doanh, trả về đối tượng phản hồi có chứa mô tả lỗi; trong trường hợp có lỗi hệ thống, hãy ném một ngoại lệ.

Answer 6

Tôi không hiểu tại sao bạn không thể làm cả hai? Nắm bắt ngoại lệ, đăng nhập nó (hoặc là một DB hoặc một tập tin), sau đó trả về một mã lỗi. Bằng cách đó bạn có một thực hiện duyên dáng của các cuộc gọi webservice, và cũng thông báo lỗi, và bạn có một chỗ ở nơi khác, bạn có thể tiếp tục gỡ lỗi.