Jaka jest różnica między HttpResponseMessage i HttpResponseException

Question

Próbowałem zrozumieć zarówno i napisać przykładowy kod:

public HttpResponseMessage Get() 
{ 
    var response = ControllerContext.Request 
         .CreateResponse(HttpStatusCode.BadRequest, "abc"); 

    throw new HttpResponseException(response); 
} 

oraz:

public HttpResponseMessage Get() 
{ 
    return ControllerContext.Request 
         .CreateResponse(HttpStatusCode.BadRequest, "abc"); 
} 

Od Fiddle, ja naprawdę nie widzę żadnych różnic między nimi , więc jaki jest cel używania HttpResponseException?

Answer 1

Główna różnica między tymi dwoma jest taka. Wyjątek jest przydatny do natychmiastowego przerwania przetwarzania i zakończenia. Na przykład założyć, mam następujący kod

public class CustomerController : ApiController { 
    private ICustomerContext repo; 

    public CustomerController(ICustomerContext repo) { 
    this.repo = repo; 
    } 

    public Customer Get(int id) { 
    var customer = repo.Customers.SingleOrDefault(c=>c.CustomerID == id); 
    if (customer == null) { 
     throw new HttpResponseException(new HttpResponseMessage(HttpStatusCode.NotFound)); 
    } 
    return customer; 
    } 
} 

Jeśli ten kod działa i mogę przekazać identyfikator, który nie jest obecny, będzie natychmiast zatrzymać przetwarzanie i zwraca kod statusu 404.

Jeśli zamiast wrócić HttpResponseMessage, żądanie z przyjemnością kontynuuje pozostałą część przetwarzania i zwraca 404. Główną różnicą jest zakończenie żądania lub nie.

Jak Darrel powiedział, że wyjątek jest przydatny w przypadkach, w których w niektórych przypadkach chcę kontynuować przetwarzanie (jak w przypadku znalezienia klienta), aw innych nie.

Miejsce, w którym możesz chcieć użyć czegoś takiego jak HttpResponseMessage, znajduje się w HST POST, aby zwrócić kod stanu 201 i ustawić nagłówek lokalizacji. W takim przypadku chcę, aby przetwarzanie było kontynuowane. Że zrobi z tym kodem *

public class CustomerController : ApiController { 
    private ICustomerContext repo; 

    public CustomerController(ICustomerContext repo) { 
    this.repo = repo; 
    } 

    public HttpResponseMessage Post(Customer customer) { 
    repo.Add(customer); 
    repo.SaveChanges(); 
    var response = Request.CreateResponse(HttpStatusCode.Created, customer); 
    response.Headers.Location = new Uri(Request.RequestUri, string.format("customer/{0}", customer.id)); 
    return response; 
    } 
} 

*. Uwaga: Jeżeli używasz bity beta chcesz utworzyć nowy HttpResponseMessage. Używam późniejszych bitów, które jednak wymagają użycia metody rozszerzenia CreateResponse z Żądania.

Powyżej tworzę odpowiedź, która ustawia kod statusu na 201, przechodzi w kliencie, a następnie ustawia nagłówek lokalizacji.

Odpowiedź jest zwracana, a żądanie kontynuuje przetwarzanie.

Nadzieja to pomaga

Answer 2

wywodzi się z Exception i osadza HttpResponseMessage. Ponieważ pochodzi od Exception, może być przydatny w scenariuszach try - catch.

Domyślny kod stanu zwrócony przez HttpResponseException to HttpStatusCode.InternalServerError.

Answer 3

HttpResponseException jest przydatna, gdy podpis Action Controller wygląda

Foo Get(int id) 

W tym przypadku nie można łatwo powrócić kod stanu jak 400.

Należy pamiętać, że HttpResponseMessage<T> zniknie w następnym wydaniu Web API.

Answer 4

Zakładając chcesz testów jednostkowych odpowiedzi, nie jest sens, aby zawsze zwracać HttpResponseMessage? Nie podoba mi się zwłaszcza pomysł zwrócenia prostego typu z ApiController, ponieważ nie podąża za typowymi wzorami rozwoju.

W klasie non-Web API, które naciągane Klient, to prawdopodobnie zwróci null, a Twój kod wywołujący sprawdzanie null odpowiedzi:

public Customer GetCustomer(int id) 
{ 
    return db.Customers.Find(id); 
} 

Ale w Web API, nie zamierzamy aby zwrócić wartość null, musisz zwrócić coś, nawet jeśli coś jest tworzone po wyrzuceniu wyjątku HttpResponseException. W takim przypadku, aby ułatwić testowanie, dlaczego nie zawsze zwracasz HttpResponseMessage i tworzysz swój podpis?

public HttpResponseMessage GetCustomer(int id) 
{ 
    var customer = db.Customers.Find(id); 
    if (customer == null) 
    { 
     return Request.CreateResponse(HttpStatusCode.NotFound); 
    } 

    return Request.CreateResponse(HttpStatusCode.OK, customer); 
} 

Answer 5

Zgodnie z pierwotnymi pytaniami, w zwróconej odpowiedzi nie ma rzeczywistej różnicy.

Prawdziwym celem wyjątku HttpResponseException jest umożliwienie metodom podrzędnym tworzenia i "wyrzucania" własnych HttpResponseMessages, które powracają do stosu wywołań i są zwracane do klienta.

public class CustomerController : ApiController { 
    private ICustomerContext repo; 
    public CustomerController(ICustomerContext repo) { 
    this.repo = repo; 
    } 

    public HttpResponseMessage Get(int id) { 

    Customer customer = getCustomer(id); 

    return Request.CreateResponse(customer); 
    } 

    private Customer getCustomer(int id){ 
    .....do some work 
    .....we have a problem so throw exception 
    throw new HttpResponseException(Request.CreateResponse(HttpStatusCode.BadRequest, "Id out of range"); 
    return repo.Customers.SingleOrDefault(c=>c.CustomerID == id) 
} 

Przebaczyć ewentualne błędy, kod napisany w locie. Wyrzucony wyjątek HttpResponseException przepływa przez stos wywołań akcji, nie jest przechwytywany przez normalne procedury obsługi wyjątków i zwraca jego HttpResponseMessage, tak jak ma to miejsce w przypadku metody akcji.