Есть такой метод (упростил):

public int getLenght(String s1, String s2){
    return s1.length() + s2.length();
}

Если одна из строк null -- должно выбрасываться исключение.

В C# обычно так написать считается ошибкой: нужно проверить аргументы на null и лично выбросить ArgumentNullException. В Java, как я понял, так не принято. Т.е. пусть система выбрасывает NullPointerException -- ничего страшного в этом нет. Правильно ли я понял?

Здравствуйте, 0K, Вы писали:

0K>В Java, как я понял, так не принято. Т.е. пусть система выбрасывает NullPointerException -- ничего страшного в этом нет. Правильно ли я понял?
Да. Принято вообще свести возможность появления null значений во всей системе к минимуму.

Здравствуйте, 0K, Вы писали:

0K>В C# обычно так написать считается ошибкой: нужно проверить аргументы на null и лично выбросить ArgumentNullException. В Java, как я понял, так не принято. Т.е. пусть система выбрасывает NullPointerException -- ничего страшного в этом нет. Правильно ли я понял?

Погуглил на тему ArgumentNullException vs NullReferenceException, так и не понял в чем задумка. Большинство ответов сводятся к тому что NullReferenceException не является вызовом метода у null ссылки, поэтому его нельзя выбрасывать, так как это введет в заблуждение девелопера. Непонятно.

Здравствуйте, Blazkowicz, Вы писали:


B>Погуглил на тему ArgumentNullException vs NullReferenceException, так и не понял в чем задумка. Большинство ответов сводятся к тому что NullReferenceException не является вызовом метода у null ссылки, поэтому его нельзя выбрасывать, так как это введет в заблуждение девелопера. Непонятно.

Больше того. В J2SE полно кода вида

    if (variable == null)
        throw new NullPointerException();

Здравствуйте, 0K, Вы писали:

0K>Есть такой метод (упростил):

0K>

0K>public int getLenght(String s1, String s2){
0K>    return s1.length() + s2.length();
0K>}
0K>

0K>Если одна из строк null -- должно выбрасываться исключение.

0K>В C# обычно так написать считается ошибкой: нужно проверить аргументы на null и лично выбросить ArgumentNullException. В Java, как я понял, так не принято. Т.е. пусть система выбрасывает NullPointerException -- ничего страшного в этом нет. Правильно ли я понял?

Моё мнение — надо проверять все аргументы в публичных методах и выбрасывать исключение с именем параметра, который равен null. А ещё лучше использовать аннотацию @Nullable и обрабатывать .class-файлы специальным инструментом, который сам добавит проверяющий код.

Полагаясь на выброс NPE можно получить неконсистентное поведение, и не очень удобный стектрейс исключения.

Здравствуйте, vsb, Вы писали:
vsb> А ещё лучше использовать аннотацию @Nullable и обрабатывать .class-файлы специальным инструментом, который сам добавит проверяющий код.

@NotNull, конечно же.

Здравствуйте, Blazkowicz, Вы писали:
B>Больше того. В J2SE полно кода вида

B>

B>    if (variable == null)
B>        throw new NullPointerException();
B>

Может легасевый код и язык не всегда гарантировал NullPointerException при обращении к null-pointer ? Ну или просто идиотизм

Здравствуйте, vsb, Вы писали:

vsb>Моё мнение — надо проверять все аргументы в публичных методах и выбрасывать исключение с именем параметра, который равен null. А ещё лучше использовать аннотацию @Nullable и обрабатывать .class-файлы специальным инструментом, который сам добавит проверяющий код.
vsb>Полагаясь на выброс NPE можно получить неконсистентное поведение, и не очень удобный стектрейс исключения.

Спорно. Если в документации к методу явно указано, что ненадо пихать null вместо ожидаемой ссылки то выброс NullPointerException гарантированный языком самое что ни на есть валидное поведение. Такие ошибки нужно фиксать а не обрабатывать

Здравствуйте, Jakop, Вы писали:

J>Может легасевый код и язык не всегда гарантировал NullPointerException при обращении к null-pointer ? Ну или просто идиотизм
Нормальный код. Такого много. Например, чтобы избежать лишних операций, которые будут производится до использования самой переменной. Либо использование переменной не всегда может быть имеенно вызовом её метода.

Здравствуйте, Jakop, Вы писали:

J>Спорно. Если в документации к методу явно указано, что ненадо пихать null вместо ожидаемой ссылки то выброс NullPointerException гарантированный языком самое что ни на есть валидное поведение. Такие ошибки нужно фиксать а не обрабатывать
Так именно о фиксе речь! Суть в том что NullPointerException происходит там где null значение уже используется. Но фактически ошибка произошла там где null значение попало в переменную. Подобные превалидирующие решения, вроде Oval, выкинут исключение именно в точке присвоения null. Таким образом ошибка быстрее обнаруживается и её исправление в одном месте лучше (логичнее ветвление начать или исправить именно в этом месте) чем проверка на null в каждом месте где используется переменная.

Здравствуйте, Blazkowicz, Вы писали:

B>Погуглил на тему ArgumentNullException vs NullReferenceException, так и не понял в чем задумка. Большинство ответов сводятся к тому что NullReferenceException не является вызовом метода у null ссылки, поэтому его нельзя выбрасывать, так как это введет в заблуждение девелопера. Непонятно.

NullReferenceException -- не связано с аргументом метода (это более общее), а ArgumentNullException создан специально для проверки параметров метода. Причем NullReferenceException вручную никто не выбрасывает -- только системные классы.

Если еще углубится ArgumentNullException -- это своего рода контракт (см. программирование по контракту).

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Jakop, Вы писали:

J>>Спорно. Если в документации к методу явно указано, что ненадо пихать null вместо ожидаемой ссылки то выброс NullPointerException гарантированный языком самое что ни на есть валидное поведение. Такие ошибки нужно фиксать а не обрабатывать
B>Так именно о фиксе речь! Суть в том что NullPointerException происходит там где null значение уже используется. Но фактически ошибка произошла там где null значение попало в переменную. Подобные превалидирующие решения, вроде Oval, выкинут исключение именно в точке присвоения null. Таким образом ошибка быстрее обнаруживается и её исправление в одном месте лучше (логичнее ветвление начать или исправить именно в этом месте) чем проверка на null в каждом месте где используется переменная.
Не вижу особого смысла вообще что-то проверять. ява выкинет исключение по нему будет ясно что случилось. Про Oval посмотрю что за зверь, но подозреваю что не без издержек на производительность это работает. Если код системы не особо сложен имеет ли это смысл ?

vsb>А ещё лучше использовать аннотацию @Nullable и обрабатывать .class-файлы специальным инструментом, который сам добавит проверяющий код.
Спорный момент. В JSE NotNull нет, и compile-time кодогенерация сильно привязывает к определенному фреймворку/процессу сборки, а в runtime через аспекты делать — имхо перебор. Если по какой-то причине кодогенератор в будущем отвалится (чуток сборку поправили и забыли включить), вы остаётесь с хорошо документированным кодом, который падает не там, где нужно. А разницы с проверкой параметра вручную — всего одна строка.

Здравствуйте, Jakop, Вы писали:

J>Не вижу особого смысла вообще что-то проверять. ява выкинет исключение по нему будет ясно что случилось.
Ясно что случилось. Но не до конца ясно где случилось. Кто тот вражина что установил переменную в null из исключения не понятно.

B>Погуглил на тему ArgumentNullException vs NullReferenceException, так и не понял в чем задумка. Большинство ответов сводятся к тому что NullReferenceException не является вызовом метода у null ссылки, поэтому его нельзя выбрасывать, так как это введет в заблуждение девелопера. Непонятно.
Разница такая же, как между IllegalArgumentException (который можно кинуть и на аргумент равный null) и NPE — чисто семантическая. NPE означает, что мы попытались обратиться к объекту, которого нет, и может произойти спустя много времени после вызова метода (например, мы можем сунуть этот null в коллекцию и потом где-то вытащить и пытаться что-то сделать). Именно поэтому имеет смысл кидать IAE в своем коде сразу после вызова метода, если встретился null. То, что в JSE бросают NPE вместо IAE, скорее всего ошибка проектирования стандартной библиотеки.

Здравствуйте, Baudolino, Вы писали:

B>То, что в JSE бросают NPE вместо IAE, скорее всего ошибка проектирования стандартной библиотеки.
Что ж все такие скептичные "ошибка", "идиоты". Всё там нормально. Сначала проверется на null, потом валидируется значение. Бросать IllegalArgumentException на null значение особого смыса я не вижу.

        if (oldContext == null)
        throw new NullPointerException();

    /* Check that the restored context is in the stack.  */
    for (ThreadContext context = getContext();
         context != oldContext;
         context = context.previous) {
        if (context == null) {
        throw new IllegalArgumentException("Restored context is not " +
                           "contained in current " +
                           "context");
        }
    }

Здравствуйте, Baudolino, Вы писали:

Толковый тред по теме
http://stackoverflow.com/questions/3881/illegalargumentexception-or-nullpointerexception-for-a-null-parameter

B>Что ж все такие скептичные "ошибка", "идиоты". Всё там нормально. Сначала проверется на null, потом валидируется значение.
А проверка на null уже не является частью проверки корректности значения вообще? Почему этот случай выделяется целым отдельным исключением? Где логика?

B>Толковый тред по теме
B>http://stackoverflow.com/questions/3881/illegalargumentexception-or-nullpointerexception-for-a-null-parameter
Ч.Т.Д.

Здравствуйте, Baudolino, Вы писали:

B>>Толковый тред по теме
B>>http://stackoverflow.com/questions/3881/illegalargumentexception-or-nullpointerexception-for-a-null-parameter
B>Ч.Т.Д.
Дальше второго поста не дочитал?