2012-04-10 10 views
31

Sto provando a verificare l'esistenza di un URL utilizzando HttpWebRequest. Ho trovato alcuni esempi che fanno fondamentalmente questo:Perché HttpWebRequest lancia un'eccezione invece di restituire HttpStatusCode.NotFound?

HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(Url); 
request.Method = "HEAD"; 
using (HttpWebResponse response = request.GetResponse() as HttpWebResponse) 
{ 
    return response.StatusCode; 
} 

Tuttavia, se l'URL è infatti rotto, non è il ritorno di una risposta, è invece un'eccezione.

ho modificato il mio codice a questo:

try 
{ 
    HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(Url); 
    request.Method = "HEAD"; 
    using (HttpWebResponse response = request.GetResponse() as HttpWebResponse) 
    { 
     return response.StatusCode; 
    } 
} 
catch (System.Net.WebException ex) 
{ 
    var response = ex.Response as HttpWebResponse; 
    return response == null ? HttpStatusCode.InternalServerError : response.StatusCode; 
} 

che sembra fare finalmente quello che voglio.

Ma mi piacerebbe sapere, perché la richiesta genera un'eccezione invece di restituire la risposta con un codice di stato NotFound?

risposta

54

Ya può essere abbastanza fastidioso quando le pagine Web utilizzano i codici di stato pesantemente e non tutti sono errori. Il che può rendere l'elaborazione del corpo un bel dolore. Personalmente utilizzo questo metodo di estensione per ottenere la risposta.

public static class HttpWebResponseExt 
{ 
    public static HttpWebResponse GetResponseNoException(this HttpWebRequest req) 
    { 
     try 
     { 
      return (HttpWebResponse)req.GetResponse(); 
     } 
     catch (WebException we) 
     { 
      var resp = we.Response as HttpWebResponse; 
      if (resp == null) 
       throw; 
      return resp; 
     } 
    } 
} 
+6

Sebbene questo sia il minimo lavoro per salvare il codice usando HttpWebRequest/Response da questa cattiva scelta di progettazione nella parte degli autori di .Net Framework, la soluzione corretta è usare HttpClient, che non gira sui codici di stato 4xx e 5xx. Le eccezioni sono pensate per situazioni eccezionali, e si lanciano solo per prenderlo e procedere come se andasse bene come questo è brutto e cattivo per le prestazioni, soprattutto dato che c'è un'opzione migliore che la evita del tutto. https://msdn.microsoft.com/en-us/library/hh138242(v=vs.118).aspx –

+1

questo non sembra essere vero; Sto usando HttpClient in un progetto e quando si chiama un url che non esiste che restituisce un codice di stato 404, il client lancia un'eccezione invece di restituire una risposta con il codice di stato 404. c'è un ulteriore passaggio nell'uso di httpclient per impedirlo? – SelAromDotNet

2

Perché no? Sono entrambe valide opzioni di progettazione e HttpWebRequest è stato progettato per funzionare in questo modo.

+0

Finché è possibile leggere le intestazioni di risposta e il corpo quando il codice è 4xx –

+4

immagino ero confuso, perché nessuno dei campioni di codice che ho visto per questo ha preso questo in considerazione. molti non hanno nemmeno provato/catturare, e mi chiedevo se forse mi mancava qualcosa e c'è un modo per ottenere lo status senza fare un'eccezione. sembra semplicemente controintuitivo lanciare un'eccezione se il codice statistico è progettato per gestire tale stato – SelAromDotNet

+1

Sì, porta sempre a risultati interessanti quando si pensa che "ovviamente xxx ha testato la riga di codice che ha messo sul suo sito web!" e risulta errato :) –

Problemi correlati