У меня есть решарпер HttpWebResponse, и StreamReader указывает, что мой httpResponse.GetResponseStream() может быть нулевым, но я не уверен в правильном синтаксисе.
using(var httpResponse = (HttpWebResponse)request.GetResponse())
{
if (httpResponse.StatusCode == HttpStatusCode.OK)
{
//This line is where Resharper Is complaining
using (var streamReader = new StreamReader(httpResponse.GetResponseStream()))
{
var result = streamReader.ReadToEnd();
...
}
}
else
{...
Помимо дубликата, скажите ReSharper заткнуться :) это бесполезное предупреждение
Что вы подразумеваете под "лучшим способом"? Просто сравните результат с null
, и если это сравнение вернет false
, объект не нулевой...
Извините, я подумал, потому что это был поток, который я не мог проверить заранее, иначе он был бы прочитан до конца, а затем больше не был бы доступен, и что использование позаботилось об утилизации и т. д... но я вижу, что это довольно теперь очевидно. всем спасибо!
Просто убедитесь, что httpResponse.GetResponseStream()
не возвращает нулевое значение:
using(var httpResponse = (HttpWebResponse)request.GetResponse())
{
if (httpResponse.StatusCode == HttpStatusCode.OK)
{
var responseStream = httpResponse.GetResponseStream();
if (responseStream != null)
{
// Line reached only if httpResponse.GetResponseStream() isn't null
using (var streamReader = new StreamReader(responseStream))
{
var result = streamReader.ReadToEnd();
...
}
}
}
else
{
...
}
}
Не по теме: вы можете уменьшить ненужную вложенность, инвертируя свои утверждения if
и используя return
: if (responseStream == null) return;
. Это поможет вам избежать страшного пирамида судьбы.
Я как бы следовал стилю кода, который уже был там, но да, он начинает выглядеть довольно вложенным и выиграет от некоторой уборки.
Справедливо. Хотя случай OP немного отличается, потому что у него есть предложение else
(и, поскольку мы не знаем, что в нем, мы не можем сказать, можно ли удалить предложение else с помощью той же техники рефакторинга). Мой комментарий был просто в духе обмена знаниями и облегчения чтения кода. :)
В целом вы правы. Но в этом случае я думаю, что этот код хорош, потому что его все еще легко читать, и потому что он будет работать путем копирования и вставки независимо от контекста — если я напишу пустой return
и метод, содержащий этот код, что-то вернет, тогда мой код не будет работать именно так, как есть. В любом случае, учитывая простоту этого кода, я думаю, что здесь подойдет любой вариант, но я ценю отзывы на будущее!
Да, как правило, я следую этому, но если код состояния не в порядке, происходит нечто большее, тогда я проверяю ошибку и обрабатываю уведомления в соответствующие команды/журналы, и по-прежнему имеет смысл хранить все это вместе в этом коротком методе, чем разделять его. как это все логически связано. Однако спасибо за заметку!
проверьте это перед рукой.