6

Nếu tôi thêm các dòng sau vào một phương pháp hành động ASP.NET MVCNém ngoại lệ với SecurityException bên trong chỉ hiển thị ngoại lệ bên trong ASP.NET MVC

throw new Exception("outer", new SecurityException("inner")); 

lỗi mà là thực sự hiển thị trên màn hình màu vàng của cái chết là SecurityException bên trong hoàn toàn không đề cập đến ngoại lệ bên ngoài.

SecurityException

Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator or change the application's trust level in the configuration file.

Exception Details: System.Security.SecurityException: inner

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[SecurityException: inner]

Hành vi này có được mong đợi không?

Dường như ngoại lệ ngoại lệ là gì. Ngay cả khi nó là một SecurityException khác, tin nhắn không bao giờ được hiển thị. Thông báo lỗi SecurityException mặc định quá mơ hồ đến nỗi tôi muốn bắt nó và thêm một số thông tin cụ thể hơn. Điều này làm việc tốt nếu tôi không bao gồm SecurityException gốc là innerException nhưng lý tưởng là tôi muốn làm điều này.

+0

Tôi thấy điều này đúng với bất kỳ ngoại lệ bên trong nào, không chỉ là sự an toàn. –

Trả lời

-1

nói chung bạn nên không bao giờ ném lớp Exception/đối tượng trực tiếp nhưng chỉ có nguồn gốc cái, ví dụ:

throw new SecurityException("user should not be allowed to access this method..."); 

trong một tình huống như thế này những gì bạn đang thiếu trong nhật ký hoặc trong trang?

nếu bạn sử dụng một ứng dụng xử lý ngoại lệ toàn cầu và bạn đăng nhập từ đó với một trong hai Log4Net hoặc NLog bạn sẽ có thể truy cập vào tất cả các chuỗi ngoại lệ từ bên ngoài để bên trong và vân vân tùy thuộc vào cách bạn cấu hình và sử dụng khung đăng nhập. Trang màu vàng của IIS/ASP.NET có thể chưa hoàn thành nhưng vẫn hiển thị dấu vết ngăn xếp.

nếu bạn muốn ném ngoại lệ riêng của bạn từ một khối catch bạn quấn ngoại lệ thực tế đến từ đánh bắt theo cách này:

throw new SecurityException("user should not be allowed...", exc); 

Sửa: cố gắng những gì bạn đề nghị và nhận được những sản phẩm sau đăng nhập tệp văn bản của Log4Net:

System.Security.SecurityException: more explicit exception ---> System.Security.SecurityException: original exception at EDICheckerApp.Program.boom() in C:\DEV_RPP\Program.cs:line 45
--- End of inner exception stack trace --- at EDICheckerApp.Program.boom() in C:\DEV_RPP\Program.cs:line 49
at EDICheckerApp.Program.Main(String[] args) in C:\DEV_RPP\Program.cs:line 27

+1

thử điều này và bạn sẽ hiểu những gì tôi đang nói: thử { ném SecurityException mới ("ngoại lệ ban đầu"); } bắt (SecurityException ex) { ném SecurityException mới ("ngoại lệ rõ ràng hơn", ví dụ); } –

+0

vâng tôi hiểu, nhưng cố gắng đổ toàn bộ nội dung bằng khung ghi nhật ký, bạn sẽ nhận được gì trong tệp nhật ký? –

+1

Trong trường hợp này, thông điệp chủ yếu dành cho nhà phát triển.Tôi muốn thông báo lỗi thân thiện được nâng lên để các nhà phát triển thấy nó tại thời điểm gỡ lỗi, không phải để ghi nhật ký và vì vậy họ nhận được bất kỳ thông điệp dễ hiểu nào hơn là một thông điệp khó hiểu. –

5

Hành vi này bắt nguồn từ ASP.NET "lõi", không phải trong ASP.NET MVC. Thật không may, các lớp trình định dạng lỗi là nội bộ và các kiểu tiêu thụ không cung cấp bất kỳ điểm mở rộng nào cho phép người ta chỉnh sửa hành vi mà không thay thế cơ chế báo cáo lỗi. Giải pháp thay thế là thay thế trang "màn hình màu vàng chết" mặc định bằng một trang/chế độ xem lỗi tùy chỉnh trong đó một trang hiển thị thông tin mà người dùng thích.

Đây chính xác là những gì người ta thường làm cho sản xuất. Trong trường hợp của bạn, nó chỉ có nghĩa là bạn sẽ có một phiên bản thay thế để gỡ lỗi thay vì sử dụng mặc định do ASP.NET cung cấp.

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