.NET Core/5+ - 에러 로깅을 위한 Middleware가 동작하지 않는 경우
실습을 해볼까요? ^^ .NET 6/기본 웹 애플리케이션 API 프로젝트를 만든 후, 코드에 예외를 발생하는 상황을 만들어둡니다.
// WeatherForecastController.cs
[HttpGet]
public IEnumerable<WeatherForecast> Get()
{
if (HttpContext.Request.Query.TryGetValue("test", out _) == true)
{
throw new ApplicationException("test is not null");
}
return Enumerable.Range(1, 5).Select(index => new WeatherForecast
{
Date = DateTime.Now.AddDays(index),
TemperatureC = Random.Shared.Next(-20, 55),
Summary = Summaries[Random.Shared.Next(Summaries.Length)]
})
.ToArray();
}
당연히 이 상황에서는 "http://localhost:5202/weatherforecast?test=1" 요청을 전송하면 예외가 발생할 것입니다. 자, 그럼 이 예외를 전역적으로 한 곳에서 처리하기 위해 Middleware를 하나 만들어보겠습니다.
public class ErrorLoggingMiddleware
{
private readonly RequestDelegate _next;
public ErrorLoggingMiddleware(RequestDelegate next)
{
_next = next;
}
public async Task Invoke(HttpContext context)
{
try
{
await _next(context);
}
catch (Exception e)
{
System.Diagnostics.Debug.WriteLine($"The following error happened: {e.Message}");
}
}
}
그리고 이것을 .NET Core/5+ Pipeline에 등록해 주면,
// Program.cs
public static void Main(string[] args)
{
var builder = WebApplication.CreateBuilder(args);
// Add services to the container.
builder.Services.AddControllers();
var app = builder.Build();
// Configure the HTTP request pipeline.
app.UseMiddleware<ErrorLoggingMiddleware>();
app.UseAuthorization();
app.MapControllers();
app.Run();
}
이후 "http://localhost:5202/weatherforecast?test=1" 요청에 대해 ErrorLoggingMiddleware.Invoke 내에서 try/catch에 걸려 System.Diagnostics.Debug.WriteLine 코드가 동작하는 것을 확인할 수 있습니다.
그런데, ErrorLoggingMiddleware가 동작하지 않을 수도 있습니다. 왜냐하면 Web API를 처리하는 또 다른 Middleware가 등록돼 중간에서 예외를 가로챌 수 있기 때문입니다. 그리고 그러한 가장 대표적인 예가 ASP.NET Core에서 제공하는 "
DeveloperExceptionPageMiddleware"입니다. 그래서 이것을 우리가 만든 Middleware 다음에 등록하면,
// ...[생략]..
// Configure the HTTP request pipeline.
app.UseMiddleware<ErrorLoggingMiddleware>();
app.UseDeveloperExceptionPage();
// ...[생략]..
Web API에서 발생한 예외를 DeveloperExceptionPageMiddleware에서 먼저 catch하게 되고 이전에 등록된 Middleware에서는 예외 처리가 안 되는 것입니다. 따라서 이런 경우 우리가 만든 ErrorLoggingMiddleware에서 예외를 받고 싶다면 UseDeveloperExceptionPage 호출을 제거해야 합니다.
이런 이유로 인해, 사실 예외 로깅을 위한 Middleware는 예외를 먹을 것이 아니라, 다시 throw하는 것이 더 바람직합니다.
public class ErrorLoggingMiddleware
{
// ...[생략]...
public async Task Invoke(HttpContext context)
{
try
{
await _next(context);
}
catch (Exception e)
{
System.Diagnostics.Debug.WriteLine($"The following error happened: {e.Message}");
throw;
}
}
}
저렇게 해주면, 우리가 만든 ErrorLoggingMiddleware는 UseDeveloperExceptionPage(또는, 예외 처리를 목적으로 하는 다른 Middleware)의 호출 위치에 상관없이 DeveloperExceptionPageMiddleware의 동작에는 영향을 주지 않습니다.
참고로, DeveloperExceptionPageMiddleware가 예외를 먹는 것이 잘못된 동작은 아닙니다. 왜냐하면 그 페이지는 예외 상황을 HTML로 구성해 내려주는 역할을 하기 때문에 거기서 다시 예외를 발생하게 되면 그러한 동작을 할 수 없게 됩니다.
더군다나, 이런 부분이 문제가 되지 않는 또 다른 이유는, 어차피 실 서비스에서는 DeveloperExceptionPageMiddleware를 사용하지 않기 때문에,
if (app.Environment.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
else
{
app.UseExceptionHandler("/Home/Error");
}
위에서처럼 UseExceptionHandler로 등록되는
ExceptionHandlerMiddleware는 우리가 만든 Middleware처럼 throw를 다시 하도록 동작합니다.
그래서 UseExceptionHandler인 경우, Middleware 순서에 상관없이 잘 동작합니다.
// 이렇게 해도,
app.UseExceptionHandler("/Home/Error");
app.UseMiddleware();
// 또는 이렇게 해도, ErrorLoggingMiddleware의 try/catch에 예외가 잡힙니다.
app.UseMiddleware();
app.UseExceptionHandler("/Home/Error");
(
첨부 파일은 이 글의 예제 코드를 포함합니다.)
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]