Thực tiễn tốt nhất là bao bọc một phương thức/cuộc gọi dịch vụ web thành một khối try/catch?Gói dịch vụ web trong khối try/catch
Tôi không yêu cầu dịch vụ web có xu hướng là lý do khiến ứng dụng .NET trên máy tính bị lỗi? Vì vậy, tôi đã suy nghĩ tất cả các cuộc gọi nên được gói trong try/catch để ngăn chặn điều này.
Ý tưởng hay?
Ngoài ra, nó có nên ném một ngoại lệ hoặc chỉ có một sản phẩm nào?
Tôi giả sử bạn đang sử dụng WCF, vì câu hỏi của bạn được gắn thẻ với nó. Một thực hành tốt trong xử lý ngoại lệ với WFC không cho phép ngoại lệ bong bóng trên dây cho người tiêu dùng của bạn, nhưng thay vào đó, hãy ném các FaultExceptions có ý nghĩa.
Bạn nên luôn luôn có một thử ... bắt khối trong hoạt động của bạn nếu có bất kỳ cơ hội một ngoại lệ có thể được tạo ra bởi nó. Nếu bạn cho phép trích xuất thô, chỉ có hai kịch bản có thể xảy ra: Nếu bạn đã định cấu hình dịch vụ của mình để cho phép chi tiết ngoại lệ trong lỗi, bạn sẽ để lộ các dịch vụ nội bộ của bạn tự mở vì vi phạm an ninh. Hoặc bạn không có cấu hình này trong dịch vụ của mình và người tiêu dùng nhận được thông báo rất chung chung cho biết có điều gì đó không ổn, điều này không hữu ích cho họ hoặc nhóm hỗ trợ.
Những gì bạn cần làm là khai báo một hoặc nhiều FaultExceptions, tùy thuộc vào thư bạn muốn người dùng nhận được từ hoạt động của bạn, trang trí chúng dưới dạng FaultContracts trên khai báo hoạt động của bạn. Sau đó, bạn có thể thử ... bắt ngoại lệ cụ thể và ném các lỗi cụ thể. Bạn cũng có thể có một thử ... bắt mà bắt ngoại lệ và ném một lỗi rất chung chung.
Chìa khóa ở đây, không tiết lộ quá nhiều thông tin về những gì đang xảy ra với hoạt động của bạn trong nội bộ - đặc biệt là dấu vết ngăn xếp!
Lỗi này chỉ là một hợp đồng dữ liệu khác, vì vậy nó được khai báo trong WSDL của bạn. Điều này có nghĩa rằng người tiêu dùng của bạn có thể bắt lỗi cụ thể và có thể phản ứng với các lỗi được ném từ hoạt động của bạn như thể nó là một ngoại lệ được ném ra khỏi mã của họ.
Hy vọng điều này sẽ hữu ích.
Joe.
đây là trường hợp có thể dẫn đến ngoại lệ bị ném, vì vậy có nó phải được bao bọc trên khối thử.
gì để làm với các xử lý ngoại lệ nó phụ thuộc vào các chương trình logic ...
Đưa một phương pháp dịch vụ web trong một khối try catch là một ý tưởng tốt, như bạn đã nêu bạn không muốn sụp đổ sự kêu gọi ứng dụng vì đã xảy ra lỗi trong phương thức dịch vụ web.
Ngoài ra, thay vì ném ngoại lệ cho khách hàng, bạn không thể làm bất cứ điều gì về nó, bạn có thể xem xét việc tất cả các phương thức dịch vụ web của bạn trả về cấu trúc hoặc lớp nhỏ có thể chứa trạng thái của cuộc gọi , mã lỗi và thông báo thân thiện có thể giải thích được lỗi.
Có, bạn nên kết thúc cuộc gọi dịch vụ web trong thử nắm bắt. KHÔNG sử dụng sản phẩm nào khi chúng (chủ yếu) là ác thuần túy. Khối catch của bạn ít nhất phải đăng nhập ngoại lệ. Tôi không biết về logic ứng dụng của bạn, nhưng có thể một số thông báo (như "thông tin từ dịch vụ không được tìm nạp do lỗi công nghệ") sẽ được hiển thị cho người dùng.
Không sao, nhưng hãy thử bắt các loại ngoại lệ mà bạn có thể xử lý.
Tránh bắt bất kỳ "Ngoại lệ" nào hoặc nếu bạn làm như vậy, hãy đăng nhập và/hoặc cảnh báo người dùng và/hoặc thử lại để gọi dịch vụ web.
Nếu đó là cửa sổ ứng dụng tạo biểu mẫu, tôi thường bao gồm dấu "Ngoại lệ" cuối cùng trong khối # DE DEBUG để tránh ẩn ngoại lệ trong khi gỡ lỗi hoặc thử nghiệm.
#if !DEBUG
catch (Exception ex)
{
// show messagebox, log, etc
}
#endif
using System;
using System.ServiceModel;
using Entities; //my entities
using AuthenticationService; //my webservice reference
namespace Application.SL.Model
{
public class AuthenticationServiceHelper
{
/// <summary>
/// User log in
/// </summary>
/// <param name="callback"></param>
public void UserLogIn(Action<C48PR01IzhodOut, Exception> callback)
{
var proxy = new AuthenticationServiceClient();
try
{
proxy.UserLogInCompleted += (sender, eventargs) =>
{
var userCallback = eventargs.UserState as Action<C48PR01IzhodOut, Exception>;
if (userCallback == null)
return;
if (eventargs.Error != null)
{
userCallback(null, eventargs.Error);
return;
}
userCallback(eventargs.Result, null);
};
proxy.UserLogInAsync(callback);
}
catch (Exception ex)
{
proxy.Abort();
ErrorHelper.WriteErrorLog(ex.ToString());
}
finally
{
if (proxy.State != CommunicationState.Closed)
{
proxy.CloseAsync();
}
}
}
}
Đây có phải là phương pháp hay hay không?