ASP.NET MVC 4, HttpException을 throw하고 HttpStatusCodeResult를 반환합니까?
RESTful 서비스를 개발 중이며 지원되지 않는 모든 URL에 대해 400을 반환하고 싶습니다.
내 질문은 언제 방법 2보다 방법 1을 선택해야하고 그 반대의 경우도 마찬가지입니다.
//method 1
public ActionResult Index()
{
//The url is unsupported
throw new HttpException(400, "Bad Request");
}
이게 더 나은 것 같나요?
//method 2
public ActionResult Index()
{
//The url is unsupported
return new HttpStatusCodeResult(HttpStatusCode.BadRequest, "Bad Request");
}
두 번째는 첫 번째 예제와 비교하여 마이크로 비용으로 발생하는 예외 발생을 포함하지 않기 때문에 더 좋아 보입니다.
DevOps 팀에 속해 있기 때문에 우리는 모두 약간 더 나은 결과를 얻기 위해 더 많은 하드웨어를 사용하는 것이 항상 좋은 이유라는 사고 방식에 있습니다. 그래서 나는 의도적으로 .NET 예외를 발생시키는 마이크로 비용을 무시하고 있습니다.
ApplicationInsights 와 같은 원격 분석 프레임 워크를 활용하는 경우 상태 코드 만 반환하면 "실패한 요청"에 지나지 않습니다. 실패한 요청의 "이유"에 대한 정보를 컴파일하거나 얻을 수있는 유용한 정보를 제공하지 않습니다.
원격 분석 플랫폼은 오류 원격 분석이 일반적으로 .NET 예외와 관련이 있기 때문에 예상하고 던지기를 원하므로 던지지 않으면 작업에 문제가 발생합니다.
사람들이 작성하기를 좋아하는 프로젝트를 위해 Roslyn 분석기와 CodeFix를 작성하는 과정에 try{} catch { return BadRequest("put_the_reason_here"); }
있고 DevOps 나 Dev 팀 모두 ApplicationInsights의 시스템 원격 측정에서 유용한 정보를 보지 못 하기 때문에 실제로 여기에 도착했습니다 .
제 생각에는 지원되지 않는 URL에 대한 요청이 있는지 먼저 고려해야합니다. 그렇다면 그것이 예외적 인 상황이라고 생각합니까, 아니면 그럴 것으로 예상합니까? 예외적 인 상황으로 생각하면 예외를 생성하고 throw합니다 (옵션 1). 지원되지 않는 URL에서 많은 요청을받을 것으로 예상되는 경우이를 애플리케이션의 기능으로 취급하고 방법 2를 사용하십시오.
즉, 지원되지 않는 URL에 대해 너무 많은 요청이 예상되는 경우 클라이언트에 대해 다시 생각해야합니다. 일반적으로 지원되지 않는 URL에 대해 너무 많은 요청을받을 것으로 예상하지 않기 때문에 예외를 던지는 것을 선호하며, 발생하는 경우 예외로 기록하고 이유를 조사하고 싶습니다.
이 질문은 조금 오래되었지만 나는 이것을 발견 한 이후로 내 의견을 줄 것이라고 생각했습니다.
오류는 값입니다. 이것은 HttpException
(던져지지 않은 경우)뿐만 아니라 HttpStatusCodeResult
. 그러나 예외가 발생하면 동료에게 숨겨져있는 새 코드 경로가 생성됩니다.이 경로는 동료보다 더 높은 하나의 실행 컨텍스트 일 수 있으며 이러한 코드 경로가 통지없이 그들에게 전달된다는 문서를 제공 받아야합니다. 그러나 값은 유형을 통해 알아야 할 모든 것을 알려줍니다. 예상 실행 경로에서 해당 유형을 사용하여 오류가 발생했는지 여부를 알 수있을뿐만 아니라 해당 오류와 관련된 정보를 찾아 기록 할 수 있습니다.
나는 때때로 Exception
David Rodriguez가 언급 한 유용한 디버그 정보를 추출하기 위해 다음 실행 컨텍스트로 던지지 않고 (약간 확장 된) 를 사용합니다. 실제로 예외가 아닌 실행 컨텍스트에 throw 된 예외를 처리 할 변명은 없습니다. 이것은 실제로 코드가 처리 할 수있는 능력 밖에있는 것에 만 적용됩니다 ( StackOverflowException
, 기타 치명적인 시스템 예외 등).
실행중인 MVC 서비스와 같은 네트워크 애플리케이션에서 예외 발생으로 인한 성능 저하는 의미가 없습니다. 유지 관리 가능성에 대한 의미와 효과는 그렇지 않습니다.
네트워크 오류는 값이므로 그렇게 처리해야합니다.
'programing' 카테고리의 다른 글
Python에서 구성 파일을 어디에 넣을까요? (0) | 2021.01.15 |
---|---|
Popen.communicate 이해 (0) | 2021.01.15 |
Maven 저장소에서 오래된 종속성을 정리하는 방법은 무엇입니까? (0) | 2021.01.15 |
부트 스트랩 3-점보트론 배경 이미지 효과 (0) | 2021.01.15 |
asyncio와 다중 처리를 결합하면 어떤 종류의 문제 (있는 경우)가 있습니까? (0) | 2021.01.15 |