在《ASP.NET Core應用的錯誤處理[1]：三種呈現錯誤頁面的方式》中，我們通過幾個簡單的實例演示瞭如何呈現一個錯誤頁面，這些錯誤頁面的呈現分別由三個對應的中間件來完成，接下來我們將對這三個中間件進行詳細介紹。在開發環境呈現的異常頁面是通過一個類型為DeveloperExceptionPage... ...
在《ASP.NET Core應用的錯誤處理[1]：三種呈現錯誤頁面的方式》中，我們通過幾個簡單的實例演示瞭如何呈現一個錯誤頁面，這些錯誤頁面的呈現分別由三個對應的中間件來完成，接下來我們將對這三個中間件進行詳細介紹。在開發環境呈現的異常頁面是通過一個類型為DeveloperExceptionPageMiddleware中間件實現的。[本文已經同步到《ASP.NET Core框架揭秘》之中]
1: public class DeveloperExceptionPageMiddleware
2: {3: public DeveloperExceptionPageMiddleware(RequestDelegate next, IOptions<DeveloperExceptionPageOptions> options,
4: ILoggerFactory loggerFactory, IHostingEnvironment hostingEnvironment, DiagnosticSource diagnosticSource);5: public Task Invoke(HttpContext context);
6: }
如上面的代碼片段所示，當我們創建一個DeveloperExceptionPageMiddleware對象的時候需要以參數的形式提供一個IOptions<DeveloperExceptionPageOptions>對象，而DeveloperExceptionPageOptions對象攜帶我們為這個中間件指定的配置選項，具體的配置選項體現在如下另個屬性（FileProvider和SourceCodeLineCount）。
1: public class DeveloperExceptionPageOptions
2: {3: public IFileProvider FileProvider { get; set; }
4: public int SourceCodeLineCount { get; set; }
5: }
一般來說我們總是通過調用ApplicationBuilder的擴展方法UseDeveloperExceptionPage方法來註冊這個DeveloperExceptionPageMiddleware中間件，這兩個擴展方法重載採用如下的方式創建並註冊這個DeveloperExceptionPageMiddleware中間件。
1: public static class DeveloperExceptionPageExtensions
2: { 3: public static IApplicationBuilder UseDeveloperExceptionPage(this IApplicationBuilder app)
4: {5: return app.UseMiddleware<DeveloperExceptionPageMiddleware>();
6: } 7: public static IApplicationBuilder UseDeveloperExceptionPage(this IApplicationBuilder app,DeveloperExceptionPageOptions options)
8: {9: return app.UseMiddleware<DeveloperExceptionPageMiddleware>(Options.Create(options));
10: } 11: }
在《ASP.NET Core應用的錯誤處理[1]：三種呈現錯誤頁面的方式》實例演示中，我們並不曾使用過DeveloperExceptionPageOptions這個對象，對於定義在這個類型中的這兩個屬性，我想很多人都不知道它們究竟可以用作哪方面的配置。要很清楚地解答這個問題，就需要從 DeveloperExceptionPageMiddleware中間件處理的兩種異常類型說起。總的來說，該中間件處理的異常大體上可以分為兩類，它們分別是“運行時異常”和“編譯異常”，後者類型實現了ICompilationException介面，如下的代碼片段基本上體現了異常處理在DeveloperExceptionPageMiddleware中間件中的實現。
1: public class DeveloperExceptionPageMiddleware
2: {3: private RequestDelegate _next;
4: public async Task Invoke(HttpContext context)
5: {6: try
7: { 8: await _next(context); 9: }10: catch(Exception ex)
11: { 12: context.Response.Clear(); 13: context.Response.StatusCode = 500; 14: 15: ICompilationException compilationException = ex as ICompilationException;
16: if (null != compilationException)
17: { 18: await DisplayCompilationException(context, compilationException); 19: }20: else
21: { 22: await DisplayRuntimeException(context, ex); 23: } 24: } 25: } 26: 27: private Task DisplayRuntimeException(HttpContext context, Exception ex);
28: private Task DisplayCompilationException(HttpContext context,ICompilationException compilationException) ;
29: }
一、 處理編譯異常
我想很多人會很疑惑：我們編寫一個ASP.NET Core應用應該是先編譯成程式集，然後再部署並啟動執行，為什麼運行過程中還會出現“編譯異常”呢？從ASP.NET Core應用層面來說，我們採用的是“預編譯”，也就說我們部署的不是源代碼而是編譯好的程式集，所以運行過程中根本就不存在“編譯異常”一說。但是不要忘了在一個ASP.NET Core MVC應用中，視圖文件（.cshtml）是支持“動態編譯”的。也就是說我們可以直接部署視圖源文件，應用在執行過程中是可以動態地編譯它們的。換句話說，由於視圖文件支持動態編譯，我們是可以在部署環境直接修改視圖文件的。
對於DeveloperExceptionPageMiddleware中間件來說，對於普通的運行時異常，它會採用HTML文檔的形式將異常自身的詳細信息和當前請求的信息以HTML文檔的形式呈現出來，我們前面演示的實例已經很好的說明瞭這一點。如果應用在動態編譯視圖文件中出現了編譯異常，最終呈現出來的錯誤頁面將具有不同的結構和內容，我們不防也通過一個簡單的實例來演示一下DeveloperExceptionPageMiddleware中間件針對編譯異常的處理。
我們通過如下所示的代碼啟動了一個ASP.NET Core MVC應用，並通過調用ApplicationBuilder的擴展方法UseDeveloperExceptionPage註冊了DeveloperExceptionPageMiddleware中間件。對應定義在HomeController中的Action方法Index來說，它會負責將對應的視圖呈現出來。
1: public class Program
2: {3: public static void Main()
4: {5: new WebHostBuilder()
6: .UseKestrel() 7: .UseContentRoot(Directory.GetCurrentDirectory()) 8: .ConfigureServices(svcs => svcs.AddMvc()) 9: .Configure(app => app 10: .UseDeveloperExceptionPage() 11: .UseMvc()) 12: .Build() 13: .Run(); 14: } 15: } 16: 17: public class HomeController : Controller
18: {19: [HttpGet("/")]
20: public IActionResult Index()
21: {22: return View();
23: } 24: }
根據約定，Action方法Index呈現出來的視圖文件對應的路徑應該是“~/views/home/index.cshtml”,我們為此在這個路徑下創建這個視圖文件。為了能夠在動態編譯過程中出現編譯異常，我們在這個視圖文件中編寫瞭如下三行代碼，Foobar是一個尚未被創建的類型。
1: @{ 2: var value = new Foobar();
3: }
當我們利用瀏覽器訪問HomeController的Action方法Index的時候，應用會動態編譯目標視圖，由於視圖文件中使用了一個不曾不定義的類型，動態編譯會失敗，響應的錯誤信息會以如圖7所示的形式出現在瀏覽器上。可以看出錯誤頁面顯示的內容和結構與前面演示的實例是完全不一樣的，我們不僅可以從這個錯誤頁面中得到導致編譯失敗的視圖文件的路徑（“Views/Home/Index.cshtml”）,還可以直接看到導致編譯失敗的那一行代碼。不僅如此，這個錯誤頁面還直接將參與編譯的源代碼（不是定義在.cshtml文件中的原始代碼，而是經過轉換處理生成的C#代碼）。毫無疑問，這個如此詳盡的錯誤頁面對於相信開發人員的糾錯針對是非常有價值的。
一般來說，動態編譯的整個過程由兩個步驟組成，它先是將源代碼（類似於.cshtml這樣的模板文件）轉換成針對某種.NET語言（比如C#）的代碼，然後進一步地編譯成IL代碼。動態編譯過程中拋出的異常類型一般會實現ICompilationException介面。如下麵的代碼片段所示，該介面值具有一個唯一的屬性CompilationFailures，它返回一個元素類型為CompilationFailure的集合。編譯失敗的相關信息被封裝在一個CompilationFailure對象之中，我們可以利用它得到源文件的路徑（SourceFilePath）和內容（SourceFileContent），以及源代碼轉換後交付編譯的內容。如果在內容轉換過程就已經發生錯誤，那麼SourceFileContent屬性可能返回Null。
1: public interface ICompilationException
2: { 3: IEnumerable<CompilationFailure> CompilationFailures { get; } 4: } 5: 6: public class CompilationFailure
7: {8: public string SourceFileContent { get; }
9: public string SourceFilePath { get; }
10: public string CompiledContent { get; }
11: public IEnumerable<DiagnosticMessage> Messages { get; }
12: … 13: }
CompilationFailure類型還具有一個名為Messages的只讀屬性，它返回一個元素類型為DiagnosticMessage的集合，一個DiagnosticMessage對象承載著一些描述編譯錯誤的診斷信息。我們不僅可以藉助DiagnosticMessage對象的相關屬性得到描述編譯錯誤的消息（Message和FormattedMessage），還可以得到發生編譯錯誤所在源文件的路徑（SourceFilePath）以及範圍，StartLine、StartColumn、EndLine和EndColumn屬性分別表示導致編譯錯誤的源代碼在源文件中開始和結束的行與列（行數和列數分別從1和0開始計數）。
1: public class DiagnosticMessage
2: {3: public string SourceFilePath { get; }
4: public int StartLine { get; }
5: public int StartColumn { get; }
6: public int EndLine { get; }
7: public int EndColumn { get; }
8: 9: public string Message { get; }
10: public string FormattedMessage { get; }
11: … 12: }
從上圖可以看出，錯誤頁面會直接將導致編譯失敗的相關源代碼顯示出來。具體來說，它不僅僅會將直接導致失敗的源代碼實現出來，還會同時顯示前後相鄰的源代碼。至於相鄰源代碼應該顯示多少行，實際上是通過DeveloperExceptionPageOptions的SourceCodeLineCount屬性控制的。
1: public
