2009-07-26 23 views
12
WebResponse response; 
try 
{     
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url); 
request.Timeout = 20000; 
response = request.GetResponse(); 

request = (HttpWebRequest)WebRequest.Create(url2); 
response = request.GetResponse(); 
} 
catch(Exception ex) 
{ 
//do something 
}    
finally 
{ 
} 

nên trả lời ở đâu.Khi nào nên gọi cho WebResponse.Close()

  • sau mỗi GetResponse() để thử?

  • sau lần GetResponse cuối cùng() để thử - một lần?

  • cuối cùng là chặn?

Trả lời

19

Không có ở trên. Bạn nên sử dụng một khối using:

HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url); 
request.Timeout = 20000; 
using (WebResponse response = request.GetResponse()) 
{ 
    using (var stream = response.GetResponseStream()) 
    { 
     using (var reader = new StreamReader(stream)) 
     { 
      var result = reader.ReadToEnd(); 
      // Do something with result 
     } 
    } 
} 

Một khối using sẽ đảm bảo rằng phương thức Dispose được gọi, có hoặc không có một ngoại lệ. Vứt bỏ sẽ làm điều tương tự như Đóng.

using (var d = new DisposableClass()){code;} 

tương đương với:

DisposableClass d = null; 
try 
{ 
    d = new DisposableClass(); 
    code; 
} 
finally 
{ 
    if (d != null) 
     ((IDisposable)d).Dispose(); 
} 
+1

Để có giải thích chi tiết hơn, bạn có thể chỉ ra cách tất cả những câu lệnh sử dụng câu lệnh được chuyển thành câu lệnh try/finally :) Chỉ có lý do tôi nói điều này là vì anh ta hỏi liệu anh ta có nên đặt nó vào một câu cuối cùng không ... Rõ ràng là trong một cách sạch hơn/dễ đọc hơn. –

+0

Chắc chắn điều này phải có thể thực hiện được mà không cần sử dụng 'sử dụng', chỉ là tiêu chuẩn cố gắng nắm bắt các khối cuối cùng? – UpTheCreek

+0

Có bắt buộc phải hủy bỏ cá thể WebResponse không? Tôi không thấy vứt bỏ trong IntelliSense của Vs2008. –

1

Đặt mã vào khối cuối cùng. Theo MSDN:

Các khối finally là hữu ích cho dọn dẹp bất kỳ nguồn lực phân bổ trong khối try cũng như chạy bất kỳ mã mà phải thực hiện ngay cả khi có là một ngoại lệ. Kiểm soát luôn là được chuyển đến khối cuối cùng bất kể về cách thoát khối thử.

+0

Nhưng nếu anh ta đặt response.Close() cuối cùng anh ta sẽ nhận được lỗi 'sử dụng biến chưa được gán'. – UpTheCreek

-1

tôi sẽ đề nghị dưới đây

 try 
     { 
      HttpWebRequest request = (HttpWebRequest)WebRequest.Create("http://www.google.com"); 
      request.Timeout = 20000; 
      using (var response = request.GetResponse()) 
      { 
       //Do something with response. 
      } 


      request = (HttpWebRequest)WebRequest.Create("http://www.bing.com"); 
      using (var response = request.GetResponse()) 
      { 
       //Do somehing with response 
      } 
     } 
     catch (Exception ex) 
     { 
      //do something 
     } 
     finally 
     { 
     } 
+1

Chắc chắn bạn cần phải vứt bỏ/Đóng ví dụ "yêu cầu" đầu tiên, vì bạn chỉ ghi đè lên thể hiện đó bằng một phiên bản mới, bạn đang ở lòng thương xót của bộ sưu tập Thùng rác khi lần đầu tiên được xử lý. – Marineio

+2

WebRequest không triển khai IDisposable. –

+0

Không có lý do gì cho một khối 'cuối cùng' ở đây. Ngoài ra, nếu không có một số mã thực trong 'catch', câu trả lời này có thể để lại ấn tượng sai rằng' try/catch' là bắt buộc xung quanh tất cả các mã. –

0

Lưu ý rằng lồng nhau bằng khối không cần dấu ngoặc nhọn, cải thiện khả năng đọc. Vì vậy, mã của John Saunder có thể được viết:

HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url); 
request.Timeout = 20000; 
using (WebResponse response = request.GetResponse()) 
using (var stream = response.GetResponseStream()) 
using (var reader = new StreamReader(stream)) 
{ 
    var result = reader.ReadToEnd(); 
    // Do something with result 
} 

VS.NET hiểu rằng các khối lồng nhau đó không cần thụt đầu dòng. Lưu ý btw rằng nếu bạn biết mã hóa của phản hồi hoặc sẽ bỏ qua nó, WebClient cung cấp một API đơn giản hơn - thiếu thông tin tiêu đề, vì vậy phát hiện mã hóa dựa trên tiêu đề (chuyển/văn bản) trở thành không thể, nhưng nếu không nó hoạt động tốt.

+0

Tôi cho rằng điều này làm giảm khả năng đọc. Tôi hầu như luôn luôn thêm niềng răng, ngay cả trên một dòng nếu báo cáo, ngoại trừ trường hợp hiếm hoi như "nếu (đơn giản-điều kiện) trở lại;" –

+1

Đối với các đoạn mã ngắn có thể - đối với các tệp thực, việc thêm các dấu ngoặc không cần thiết trên các dòng dư thừa có nghĩa là mã của bạn trở nên dài hơn và ít khớp hơn trên một màn hình, nghĩa là bạn sẽ có tổng quan ít hơn. Các gợi ý thực sự anyhow nên được thụt đầu dòng, và VS.NET tự động indents mã như vậy trong một thời trang không khó hiểu. –

Các vấn đề liên quan