Нужно ли проверять значение null

Я знаю, что вы всегда должны проверять входящие параметры на метод для null. Но что, если у меня есть этот сценарий с try/catch, ссылающийся на локальную переменную. Нужно ли мне проверять нуль ниже? Потому что он все равно поймает его, если он будет нулевым, а следующая строка кода попытается использовать переменную 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();
        }
    }

Помните, что я говорю конкретно о локальных переменных и проверяет их внутри метода, а не входящие параметры метода.

Все, что я прошу здесь, это мне нужно проверить значение null перед установкой refundTransactionID или просто установить его без if, если предполагается, что компилятор будет обрабатывать и бросать, если он является нулевым, который будет пойман и отброшен как строка для вызывающего абонента в этом случае.

или он должен быть

if (refundResponse == null)
                return null;

или просто полностью выберете для этого локального назначения переменных, а затем, поскольку в этом случае у меня есть try/catch, я обрабатываю любые исключения, собранные компилятором, естественно, возвращая исключение в виде строки для вызывающего ( это было не мое решение отправить обратно строку, это было требование моего босса... поэтому обойти эту дискуссию на данный момент):

 refundTransactionID = refundResponse.RefundTransactionID;

в конечном итоге остальная часть кода дальше по линии в методе зависит от действительного refundTransactionID.

Ответ 1

Исключения для исключительных условий. Если вы можете проверить непрерывную ошибку, сделайте это, пожалуйста!

Ответ 2

Я знаю, что вы всегда должны проверять входящих параметров в метод для null.

Нет, не обязательно. То, что вы должны указать, - это контракт вашего метода. Это совершенно приемлемо (и обычно), чтобы указать, что вы будете вызывать исключение NullPointer/NullReferenceException для параметра null. Тогда вам не нужна проверка.

Вы также можете проверить значение null, но это имеет смысл только в том случае, если вы действительно можете эффективно обрабатывать нуль (например, заменять значение по умолчанию).

Ответ 3

Вам нужно будет проверить значение null в этом экземпляре. Логика вашего приложения должна иметь возможность обрабатывать такие ситуации без необходимости исключений.

Ответ 4

Альтернативой тестированию является шаблон Null Object. Вместо того, чтобы возвращать Null или действительную транзакцию, метод транзакции:: DoRefund() возвращает нулевой объект: объект, который предлагает тот же интерфейс, что и экземпляры RefundTransactionResponseType, но его методы ничего не делают. При этом нет необходимости проверять, для Null.

Следует использовать мудро, поскольку это может легко скрыть проблемы.

Ответ 5

Нет, вам не нужно проверять нулевое значение. Тем не менее, возникает другой вопрос: действительно ли вам нужно проверить наличие нулевого параметра?

Помните: это поведение. Вы должны проверить это поведение.

Ответ 6

Но если вы не можете продолжить в этот момент, пусть исключение распространяется.

Ответ 7

Нет, похоже, что вы должны проверить здесь null. И я также не буду проверять значение null для ВСЕХ входящих параметров (как показывает ваше описание).

Также странно, что вы возвращаете идентификатор транзакции как строку ИЛИ сообщение об исключении. Как вызывающий из этого метода узнает, произошло ли исключение?

Если вы действительно хотите регистрировать исключение, как насчет чего-то вроде этого:

    public string DoRefund(...) 
    { 
        try 
        {
            return transaction.DoRefund(...).RefundTransactionID; 
        } 
        catch (Exception ex) 
        { 
            LogError(ex); 
            throw ex;
        } 
    }

Ответ 8

Вы должны проверить значение null, а не обрабатывать обработку исключений. Как сказал Леппи, исключения для исключительных условий не являются нормальным потоком контроля. Если вы знаете, какие проблемы могут возникнуть, вы должны изящно обращаться с ними.

Еще одна вещь, о которой нужно помнить, - это влияние исключений производительности. Когда генерируется исключение, JVM должен отключить стек вызовов. В вашем примере затем также регистрируется исключение. Все это требует времени и намного медленнее, чем простая проверка "если".

Ответ 9

Я бы предложил проверить нуль, а затем сделать какую-то мягкую обработку ошибок, а не просто позволить ей поймать и выбросить сообщение об ошибке.

Ответ 10

Это зависит от того, что это означает для вашей программы, когда (refundResponse == null). Если это имеет какое-то значение, тогда имеет смысл сообщить более информативную ошибку. Если это никогда не произойдет и будет указывать на недостаток метода DoRefund, тогда я думаю, что это нормально, чтобы null мог вызвать исключение позже. В последнем случае у меня будет только конкретная проверка, если вы подозрительно относитесь к методу и ведете ли он себя так, как предполагалось.