Xử lý ngoại lệ ASP.NET MVC Web API

Question

Tôi sẽ bắt đầu với, vâng, chúng tôi đã tạo và đang sử dụng bộ lọc ngoại lệ kế thừa từ ExceptionFilterAttribute. Nó được đăng ký trong cấu hình khi khởi động ứng dụng ngay sau bộ lọc nhận dạng của chúng tôi và hoạt động khá nhiều như mong đợi nếu một lỗi xảy ra ở đâu đó bên trong API của chúng tôi.

Điều đó đang được nói, tôi đang tìm cách xử lý các lỗi xảy ra trước khi nó đạt đến API.

Lý do: Chúng tôi không bao giờ muốn trả lại lỗi YSOD và/hoặc lỗi HTML IIS. Chúng tôi LUÔN LUÔN muốn nhấn bộ lọc/bộ lọc ngoại lệ tùy chỉnh để chúng tôi có thể xử lý ghi nhật ký chính xác và trả về phản hồi JSON cho người dùng.

Ngay bây giờ, sử dụng Fiddler để thực hiện một yêu cầu, tôi có thể đính kèm vào quá trình w3wp.exe và xem yêu cầu nhấn phương thức Application_BeginRequest trong global.asax. Sau đó, nó chỉ trả về một câu trả lời 500. Nó không bao giờ phá vỡ trong mã với một ngoại lệ hoặc truy cập bất kỳ điểm break của tôi sau đó. Có vẻ như nó đang trả về lỗi IIS. Chúng tôi không bao giờ muốn điều này xảy ra. Chúng tôi cần khả năng nắm bắt tất cả các ngoại lệ "cấp thấp" này, ghi lại chúng và trả lại một cái gì đó có ý nghĩa cho người dùng.

Có điều gì đó chúng ta có thể làm để xử lý các lỗi trước đây, những gì có vẻ là nhấn mã ASP.NET MVC Web API?

Answer 1

Mặc dù tôi thích câu trả lời của Darin nhưng nó không hoạt động trong trường hợp của chúng tôi vì khung ASP.NET MVC Web API chặn/xử lý ngoại lệ nội bộ và không tái ném để nhấn phương thức Application_Error trong Global.asax. Giải pháp của chúng tôi là điều này.

tôi đã kết thúc việc tạo ra một DelegatingHandler tùy chỉnh như sau:

public class PrincipalHandler : DelegatingHandler 
{ 
    protected const string PrincipalKey = "MS_UserPrincipal"; 
    protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken) 
    { 
     setAnonymousPrincipal(); 

     request = InitializeIdentity(request); 

     return base.SendAsync(request, cancellationToken) 
      .ContinueWith(r => 
           { 
            // inspect result for status code and handle accordingly 
            return r.Result; 
           }); 
    } 
} 

sau đó tôi đưa nó vào trong HttpConfiguration để chắc chắn rằng nó là xử lý đầu tiên/cuối cùng được nhấn. Trình xử lý theo cách hoạt động trong API Web theo kiểu phân cấp. Vì vậy, trình xử lý đầu tiên sẽ được truy cập theo yêu cầu, sẽ là trình xử lý cuối cùng được nhấn vào phản hồi. Ít nhất đây là sự hiểu biết của tôi, ai đó cảm thấy tự do để sửa tôi nếu tôi sai.

public static void ConfigureApis(HttpConfiguration config) 
{ 
    config.MessageHandlers.Insert(0, new PrincipalHandler()); 
} 

Bằng cách sử dụng phương pháp này, chúng tôi hiện có thể kiểm tra mọi kết quả quay lại trong bất kỳ phản hồi nào từ API web và bộ điều khiển. Điều này cho phép chúng tôi xử lý bất kỳ đăng nhập nào có thể cần phải xảy ra do kết quả của một thứ không được trả lại như chúng tôi mong đợi. Bây giờ chúng ta có thể thay đổi nội dung của phản hồi quay lại để IIS không chèn bất kỳ trang lỗi HTML mặc định nào nếu nó thấy một số mã trạng thái HTTP nhất định.

Vấn đề duy nhất tôi có với điều này và tôi hy vọng họ thay đổi nó trong bản phát hành API sắp tới, là họ không gửi ngoại lệ sao lưu trên Tác vụ được trả về từ base.SendAsync (). Vì vậy, thông tin duy nhất chúng tôi phải đi qua là mã trạng thái HTTP và cố gắng hết sức để đưa ra câu trả lời hợp lý hoặc có thể xảy ra cho người tiêu dùng.