Проверить ли на пустой указатель
Я знаю, что необходимо всегда проверять входящие параметрические усилители к методу для пустого указателя. Но что, если у меня есть этот сценарий с попыткой/выгодой, относящейся к локальной переменной. Я должен действительно проверить на пустой указатель ниже? Поскольку это собирается ловить его так или иначе, если это является пустым, и следующая строка кода пытается использовать refundResponse переменную:
public string DoRefund(...)
{
try
{
......
string refundTransactionID = string.Empty;
......
RefundTransactionResponseType refundResponse = transaction.DoRefund(...);
if (refundResponse != null)
refundTransactionID = refundResponse.RefundTransactionID;
.....
}
catch (Exception ex)
{
LogError(ex);
return ex.ToString();
}
}
Помните, что я говорю конкретно о локальных переменных и проверяю локальные переменные в методе, не входящих параметрических усилителях к методу.
Все, что я спрашиваю здесь, делают я должен проверить на пустой указатель прежде, чем установить refundTransactionID или сделать я просто установил его без при предположении, что компилятор обработает и бросит, если это будет пустым, который будет пойман и отброшен назад как строка вызывающей стороне в этом случае.
или если это
if (refundResponse == null)
return null;
или просто возьмите выезд полностью для этого присвоения локальной переменной, и затем так как в этом случае у меня есть попытка/выгода, я обрабатываю любые исключения, взятые компилятором естественно путем возврата исключения как строки вызывающей стороне (это не было мое решение передать строку обратно, это было требование моим боссом... так обход, которые дебатируют на данный момент):
refundTransactionID = refundResponse.RefundTransactionID;
в конечном счете остальная часть кода далее по линии в методе зависит от допустимого refundTransactionID.
10 ответов
В этом случае вам нужно будет проверить значение null. Логика вашего приложения должна уметь справляться с подобными ситуациями без каких-либо исключений.
Исключения относятся к исключительным условиям. Если вы можете проверить наличие продолжаемой ошибки, сделайте это, пожалуйста!
Нет, не похоже, что здесь нужно проверять на null. И я бы также не стал проверять на null ВСЕ входящие параметры (как следует из вашего описания).
Также странно, что вы возвращаете идентификатор транзакции в виде строки ИЛИ сообщение об исключении. Как вызывающий этот метод узнает, произошло ли исключение?
Если вы действительно хотите регистрировать исключение, как насчет чего-то вроде этого:
public string DoRefund(...)
{
try
{
return transaction.DoRefund(...).RefundTransactionID;
}
catch (Exception ex)
{
LogError(ex);
throw ex;
}
}
Вы должны проверять значение null, а не позволять обработке исключений обрабатывать его. Как сказал Леппи, исключения предназначены для исключительных условий, а не для нормального потока управления. Если вы знаете, какие проблемы могут возникнуть, вам следует аккуратно их решать.
Еще одна вещь, о которой следует помнить, - это влияние исключений на производительность. Когда генерируется исключение, JVM должна раскрутить стек вызовов. В вашем примере также регистрируется исключение. Все это требует времени и намного медленнее, чем простая проверка «если».
Нет, вам не нужно проверять значение null. Однако здесь возникает другой вопрос: действительно ли вам нужно проверять значение NULL во входящих параметрах?
Помните: это поведение. Вы должны проверить это поведение.
Я знаю, что вы всегда должны проверять входящие параметры метода на null.
Нет, не обязательно. Вы должны указать контракт вашего метода. Совершенно приемлемо (и обычно) указать, что вы генерируете исключение NullPointer / NullReferenceException для параметра null . Тогда вам не нужно никаких проверок.
Вы также можете проверить наличие null, но это имеет смысл только в том случае, если вы действительно можете с пользой обработать null (например, подставить значение по умолчанию).
Альтернативой тестированию является шаблон Нулевой объект . Вместо возврата Null или действительной транзакции метод transaction :: DoRefund () возвращает нулевой объект: объект, который предлагает тот же интерфейс, что и экземпляры RefundTransactionResponseType, но его методы ничего не делают. При этом нет необходимости проверять, является ли значение Null.
Следует использовать с умом, так как это может легко скрыть проблемы.
Я бы посоветовал проверить нулевое значение, а затем выполнить некоторую мягкую обработку ошибок, вместо того, чтобы просто позволить ей уловить и выдать сообщение об ошибке.
Но если вы не можете продолжить с этого момента, позвольте исключению распространиться.
Это зависит от того, что означает для вашей программы, когда (RefResponse == null). Если это имеет какое-то значение, имеет смысл сообщить об ошибке более информативной. Если этого никогда не должно произойти и это укажет на недостаток в методе DoRefund, тогда я думаю, что допустить, чтобы значение null приводило к возникновению исключения позже, нормально. В последнем случае я бы проводил специальную проверку только в том случае, если вы подозреваете этот метод и ведет ли он себя должным образом.