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

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>Ч.Т.Д.
Дальше второго поста не дочитал?

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

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

B>Дальше второго поста не дочитал?
Читал. Товарищ, за которого проголосовало на треть меньше народу, считает, что это "best practice". Но это не аргумент.

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

B>

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

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

Гы. В том же классе:

    if (key == null)
        throw new IllegalArgumentException("null key");

B>>Где логика?
B>Логика в том что неверное значение и отсутствующее значение это не одно и тоже.
Отсутствующее значение, очевидно, неверно, поскольку приводит к исключительной ситуации. NPE в случае аргумента равного null хуже диагностирует проблему, чем IAE.

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

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

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

Во-первых может не выкинуть, если по каким то причинам управление не перейдёт в код, где это значение используется, но ошибка тем не менее останется. Сходу не приходит в голову реалистичный пример, вот пример идиотский, но код с подобным поведением встречается:

int strLengthSometimes(String str) {
    if (System.currentTimeInMillis() % 1000 < 100) {
        return str.length();
    } else {
        return -1;
    }
}

Если передавать null, то код иногда будет работать, а иногда не будет. При этом контракт подразумевает, что null не должен передаваться вообще. Чем раньше словим ошибку, тем раньше её поправим.

Во-вторых стектрейс с NPE будет содержать только строку кода. В одной строке может быть несколько ссылок, которые могут выкинуть этот NPE. В этом случае просто не получится точно узнать причину.

В-третьих будет немножко дольше определять ошибку, если исходники менялись — вытягивать нужную ревизию и т.д. Из IllegalArgumentException: str is null всё понятно и без номера строки.

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

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

за последние лет семь по ряду вопросов меня всё меньше волнует, как там "принято в Java". т.к. конкретные задачи и проблемы на моих проектах решать приходится нам, а не тем, кто "принимал во время создания Java в конце 90х".
поэтому я проверяю параметры явно сам и прошу того же самого от коллег.

теперь о том, что выбрасывать.
всё та же многолетняя практика показала, что единственно реально помогающим способом быстро понять, кто и где ошибся, что способствует быстрому исправлению реальной причины, является сочетание хороших trace-логов с говорящими строками в NPE/IAE, которые выбрасываются нашим кодом.
при этом философская разница между NPE / IAE для меня минимальна. в конце концов, код имеет полное право по факту проверки параметра выбросить NPE, если бы было выброшено NPE при отсутствии оной.

0K>

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

Есть еще встроенный механизм ассертов

можно еще писать
assert s1!=null && s1!=null;

Здравствуйте, 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 -- ничего страшного в этом нет. Правильно ли я понял?

Обычно так делается. Это с любой точек зрения правильно.
Элементарные функции должны быть максимально быстрыми и неперегружеными киданием исключений.
ИМХО кидать так исключения бред, и если легаси код написан подобным образом, то понятно почему Жава такая тормозная

public int getLenght(String s1, String s2){
    if ((s1 == null) || (s2==null)) 
       return -1;
    else 
       return s1.length() + s2.length();
}

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

R>ИМХО кидать так исключения бред, и если легаси код написан подобным образом, то понятно почему Жава такая тормозная

R>

R>public int getLenght(String s1, String s2){
R>    if ((s1 == null) || (s2==null)) 
R>       return -1;
R>    else 
R>       return s1.length() + s2.length();
R>}
R>

Бред это заменять исключения на код возврата. Видать тупые люди эти самые исключения придумали, видать в кодах возврата недостаточно хорошо разобрались.

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

DR>Есть еще встроенный механизм ассертов
DR>можно еще писать
DR>assert s1!=null && s1!=null;

Он не предназначен для валидации аргументов в публичных методах. Это кажется, чуть ли не в первом абзаце то ли доки, то ли туториала написано.

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

0K>>

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

DR>Есть еще встроенный механизм ассертов

DR>можно еще писать
DR>assert s1!=null && s1!=null;

Я где то читал, что аргументы в публичных методах не рекомендуется обрамлять ассертами.
Кто нибудь может прокоментировать за и против этой рекомендации и данного примера?

Здравствуйте, Аноним, Вы писали:

А>Я где то читал, что аргументы в публичных методах не рекомендуется обрамлять ассертами.
Не то что они не рекомендуются. Они для этого просто не предназначены.

А>Кто нибудь может прокоментировать за и против этой рекомендации и данного примера?
Тю, ассерты отключаются простым ключиком командной строки запуска JVM. Таким образом вся логика, реализованная на них, идет лесом одним простым движением руки.

Здравствуйте, Аноним, Вы писали:

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

0K>>>

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

DR>>Есть еще встроенный механизм ассертов

DR>>можно еще писать
DR>>assert s1!=null && s1!=null;

А>Я где то читал, что аргументы в публичных методах не рекомендуется обрамлять ассертами.
А>Кто нибудь может прокоментировать за и против этой рекомендации и данного примера?

А что тут коментировать? Ассерты по умолчанию вырублены и не работают пока не укажешь ключ -ea при запуска жавамашины.

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

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

R>>ИМХО кидать так исключения бред, и если легаси код написан подобным образом, то понятно почему Жава такая тормозная

R>>

R>>public int getLenght(String s1, String s2){
R>>    if ((s1 == null) || (s2==null)) 
R>>       return -1;
R>>    else 
R>>       return s1.length() + s2.length();
R>>}
R>>

B>Бред это заменять исключения на код возврата. Видать тупые люди эти самые исключения придумали, видать в кодах возврата недостаточно хорошо разобрались.

не люблю медленный код жрущий много памяти. Опыт создания и оптимизации игр под J2ME на моей стороне

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

R>не люблю медленный код жрущий много памяти. Опыт создания и оптимизации игр под J2ME на моей стороне
Ага, давайте теперь ради убогости J2ME весь Java код писать процедурами и во всю пользоватся препроцессорами. Вы бы ещё на уровне байткода оптимизации посоветовали.

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

B>Читал. Товарищ, за которого проголосовало на треть меньше народу, считает, что это "best practice". Но это не аргумент.

Точку зрения этого товарища также разделяет некто Джошуа Блох. Но за него там вообще никто не проголосовал, так что его мнение не считается.

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

R>>>ИМХО кидать так исключения бред, и если легаси код написан подобным образом, то понятно почему Жава такая тормозная
R>>>

R>>>public int getLenght(String s1, String s2){
R>>>    if ((s1 == null) || (s2==null)) 
R>>>       return -1;
R>>>    else 
R>>>       return s1.length() + s2.length();
R>>>}
R>>>

B>>Бред это заменять исключения на код возврата. Видать тупые люди эти самые исключения придумали, видать в кодах возврата недостаточно хорошо разобрались.

R>не люблю медленный код жрущий много памяти. Опыт создания и оптимизации игр под J2ME на моей стороне

Предлагаешь в точке вызова проверять, а не вернул ли метод -1 вместо того, чтобы перед вызовом проверить оба аргумента на null?
Если уж говорить об оптимизации, то в данном случае надо писать код так, чтобы null'овые значения не появлялись. И оптимизировать надо не все подряд, а только узкие места. И уж точно не надо проецировать практики, используемые в J2ME, на всю яву. Или уж жечь по полной и следовать всем заморочкам JavaCard

D>Точку зрения этого товарища также разделяет некто Джошуа Блох. Но за него там вообще никто не проголосовал, так что его мнение не считается.
Ссылка на авторитета тоже плохой аргумент.

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

D>>Точку зрения этого товарища также разделяет некто Джошуа Блох. Но за него там вообще никто не проголосовал, так что его мнение не считается.
B>Ссылка на авторитета тоже плохой аргумент.

Это один из создателей языка и платформы. И он упоминает соглашение, по которому в таких случаях необходимо кидать NPE. В общем, это такая же ссылка на авторитета, как сослаться на Рудольфа Дизеля относительно устройства дизеля.
Даже если представить, что кидать IAE в этом случае логичнее, то это не стоит того, чтобы переписывать стандартные соглашения и пытаться весь мир заставить им следовать. Хотя, конечно, при неожидаемом null логичнее видеть NPE во всех случаях.

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

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

R>>>>ИМХО кидать так исключения бред, и если легаси код написан подобным образом, то понятно почему Жава такая тормозная
R>>>>

R>>>>public int getLenght(String s1, String s2){
R>>>>    if ((s1 == null) || (s2==null)) 
R>>>>       return -1;
R>>>>    else 
R>>>>       return s1.length() + s2.length();
R>>>>}
R>>>>

B>>>Бред это заменять исключения на код возврата. Видать тупые люди эти самые исключения придумали, видать в кодах возврата недостаточно хорошо разобрались.

R>>не люблю медленный код жрущий много памяти. Опыт создания и оптимизации игр под J2ME на моей стороне

D>Предлагаешь в точке вызова проверять, а не вернул ли метод -1 вместо того, чтобы перед вызовом проверить оба аргумента на null?
D>Если уж говорить об оптимизации, то в данном случае надо писать код так, чтобы null'овые значения не появлялись. И оптимизировать надо не все подряд, а только узкие места. И уж точно не надо проецировать практики, используемые в J2ME, на всю яву. Или уж жечь по полной и следовать всем заморочкам JavaCard

D>Если уж говорить об оптимизации, то в данном случае надо писать код так, чтобы null'овые значения не появлялись.
Вот это полностью поддерживаю. Я за безопасный код и эффективный код.

D>Это один из создателей языка и платформы.
Ни язык, ни платформа не идеальны. Создатели тоже могут ошибаться — примеров тому в JSE навалом (самый яркий — работа с временем и датами).
>И он упоминает соглашение, по которому в таких случаях необходимо кидать NPE.
"by convention" — это, в данном случае, простой волюнтаризм. Для того, чтобы стандарт работал и был всеми принят, необходимо, чтобы при его разработке принимались рациональные решения. Судя по обсуждению, рационализмом в выборе NPE вместо IAE что-то не пахнет.
D>Даже если представить, что кидать IAE в этом случае логичнее, то это не стоит того, чтобы переписывать стандартные соглашения и пытаться весь мир заставить им следовать.
Как показано в примере, приведенном Blazkowicz, этому мифическому "стандартному соглашению" не следуют даже в стандартной библиотеке. Чего уж говорить о мире, который, судя по голосам за IAE на stackoverflow, предпочитает иной подход.
D>Хотя, конечно, при неожидаемом null логичнее видеть NPE во всех случаях.
Не логичнее. Почему — уже обсуждалось выше.

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

B>"by convention" — это, в данном случае, простой волюнтаризм. Для того, чтобы стандарт работал и был всеми принят, необходимо, чтобы при его разработке принимались рациональные решения. Судя по обсуждению, рационализмом в выборе NPE вместо IAE что-то не пахнет.

Соглашение об именовании — тоже волюнтаризм на первый взгляд. Уверен, что дотнетчики будут доказывать, что рациональнее именно их стандарт имен. Не будешь же предлагать изменить это соглашение, потому что голосование хоть здесь, хоть на стэке покажет, что большинство за дотнетовский вариант?

D>>Даже если представить, что кидать IAE в этом случае логичнее, то это не стоит того, чтобы переписывать стандартные соглашения и пытаться весь мир заставить им следовать.
B>Как показано в примере, приведенном Blazkowicz, этому мифическому "стандартному соглашению" не следуют даже в стандартной библиотеке. Чего уж говорить о мире, который, судя по голосам за IAE на stackoverflow, предпочитает иной подход.

Кидать IEA на null — это скорее исключение, чем правило.

D>>Хотя, конечно, при неожидаемом null логичнее видеть NPE во всех случаях.
B>Не логичнее. Почему — уже обсуждалось выше.

И выше же обсуждалось, почему логичнее
С таким подходиом NPE можно вообще выкинуть. Не могу придумать ни одного случая, когда его с такой же аргументацией нельзя заменить на какое-либо другое исключение.
Во многих случаях, особенно при написании библиотеки, код надо делать оптимальным. Ты не можешь знать, как и где будет использоваться твой метод, возвращающий, например, общий размер двух строк, передаваемых через аргументы. Вместо вызова двух методов и сложения ты усложнишь код проверкой, а не является ли какой-либо объект null'ом. Если метод будет вызываться в критичном по скорости обработки месте, получим ненужный расход ресурсов в важном куске кода. А можно просто забить на проверку и оставить проброс NPE на совести VM.
И мне сложно представить разработчика, который при передаче null'овского объекта в подобный метод действительно ожидает увидеть IAE, а не NPE.

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

D>Соглашение об именовании — тоже волюнтаризм на первый взгляд. Уверен, что дотнетчики будут доказывать, что рациональнее именно их стандарт имен. Не будешь же предлагать изменить это соглашение, потому что голосование хоть здесь, хоть на стэке покажет, что большинство за дотнетовский вариант?
В мире Java это соглашение является стандартом, которому следуют практически все. С NPE это просто не так — готов поспорить, что многие об этом даже не думают, а пишут, как придётся.

D>Кидать IEA на null — это скорее исключение, чем правило.
В чьём коде?

D>И выше же обсуждалось, почему логичнее
Где именно?

D>С таким подходиом NPE можно вообще выкинуть. Не могу придумать ни одного случая, когда его с такой же аргументацией нельзя заменить на какое-либо другое исключение.
Капитан Очевидность подсказывает случай, когда NPE является наиболее подходящим исключением (собственно, для этого и существует):

foo.doSomething(foo.someField); // где foo == null

D>Во многих случаях, особенно при написании библиотеки, код надо делать оптимальным. Ты не можешь знать, как и где будет использоваться твой метод, возвращающий, например, общий размер двух строк, передаваемых через аргументы. Вместо вызова двух методов и сложения ты усложнишь код проверкой, а не является ли какой-либо объект null'ом. Если метод будет вызываться в критичном по скорости обработки месте, получим ненужный расход ресурсов в важном куске кода. А можно просто забить на проверку и оставить проброс NPE на совести VM.
А если подумать хоть немного, какой код будет оптимальнее — тот, который сначала поработает, а потом выбросит NPE, или тот, который сразу кинет исключение на некорректный аргумент? Если вы считаете проверку корректности аргумента ненужным усложнением, я не хотел бы столкнуться однажды с вашим кодом.

D>И мне сложно представить разработчика, который при передаче null'овского объекта в подобный метод действительно ожидает увидеть IAE, а не NPE.
См.число голосов за IAE на StackOverflow. Таких разработчиков большинство и они разумны.

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

B>В мире Java это соглашение является стандартом, которому следуют практически все. С NPE это просто не так — готов поспорить, что многие об этом даже не думают, а пишут, как придётся.

Процент поменьше, но как ни банально это звучит, в случае незапланированного появления null, логичней бросить NPE, чем сидеть и классифицировать исключение по собственной шкале. Что, как я вижу, большинство и делает.

D>>Кидать IEA на null — это скорее исключение, чем правило.
B>В чьём коде?

В коде SDK. Да и практически во всем, который встречался.

D>>И выше же обсуждалось, почему логичнее
B>Где именно?

См. посты Блазковича и ссылку в нем.

B>Капитан Очевидность подсказывает случай, когда NPE является наиболее подходящим исключением (собственно, для этого и существует):

foo.doSomething(foo.someField); // где foo == null

А может сначала проверить на null и кинуть IllegalStateException? Состояние ведь действительно не располагает к вызову метода или обращению к полю.

B>А если подумать хоть немного, какой код будет оптимальнее — тот, который сначала поработает, а потом выбросит NPE, или тот, который сразу кинет исключение на некорректный аргумент? Если вы считаете проверку корректности аргумента ненужным усложнением, я не хотел бы столкнуться однажды с вашим кодом.

Оптимальнее тот, который не будет делать ненужных проверок, чтобы кинуть "правильное" с точки зрения конкретного разработчика исключение. Кстати, да, что будет быстрее:
1)две проверки и явное создание объекта с заданием ему в виде нового объекта строки описания, почему аргумент некорректный
2)Автоматическая генерация исключения виртуальной машиной при первой попытке обратиться к непроинициализированному объекту
?
И не надо передергивать. В случае написания метода, который не должен работать в ядре атомной станции, я считаю, что такая очевидная вещь, как проверка на null объектов, к которым гарантировано будет обращение в этом методе из одной строки, должна быть на совести вызывающего. К тому же ваша "проверка" в данном случае ничего не даст, кроме другого типа исключения, которое, как вам и еще некоторым разработчикам кажется, более подходит для данного случая.

D>>И мне сложно представить разработчика, который при передаче null'овского объекта в подобный метод действительно ожидает увидеть IAE, а не NPE.
B>См.число голосов за IAE на StackOverflow. Таких разработчиков большинство и они разумны.

Предпочитаю прислушиваться к создателям языка и учитывать то, что принято в JDK (хотя и с исключениями) и не пытаться ломать мозг разработчика, переключением с одного формата сообщения о null объекте на другой. Посмотрите на ядро и Collections API, которые используются каждый день.

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

B>>В мире Java это соглашение является стандартом, которому следуют практически все. С NPE это просто не так — готов поспорить, что многие об этом даже не думают, а пишут, как придётся.
D>Процент поменьше, но как ни банально это звучит, в случае незапланированного появления null, логичней бросить NPE, чем сидеть и классифицировать исключение по собственной шкале. Что, как я вижу, большинство и делает.
Да не логичнее нифига. И не большинство. Я могу хотя бы сослаться на тот же StackOverflow, а у вас вообще какие-то голословные тезисы.

D>>>И выше же обсуждалось, почему логичнее
B>>Где именно?
D>См. посты Блазковича и ссылку в нем.
Если речь о ссылке на StackOverflow, то там наиболее популярный ответ обратный.

B>>Капитан Очевидность подсказывает случай, когда NPE является наиболее подходящим исключением (собственно, для этого и существует):

foo.doSomething(foo.someField); // где foo == null

D>А может сначала проверить на null и кинуть IllegalStateException? Состояние ведь действительно не располагает к вызову метода или обращению к полю.
Это, извините, бред. При чем тут состояние (а главное, чьё?), когда явно нулевой указатель пришел откуда-то?

B>>А если подумать хоть немного, какой код будет оптимальнее — тот, который сначала поработает, а потом выбросит NPE, или тот, который сразу кинет исключение на некорректный аргумент? Если вы считаете проверку корректности аргумента ненужным усложнением, я не хотел бы столкнуться однажды с вашим кодом.
D>Оптимальнее тот, который не будет делать ненужных проверок, чтобы кинуть "правильное" с точки зрения конкретного разработчика исключение.
Это утверждение неверное и голословное. В общем случае нет точного ответа. Возможна и довольно часто встречается ситуация, когда аргумент используется после выполнения довольно большого числа операций (возможно, вообще не в этом методе — сунули в коллекцию и забыли). Соотв. появление NPE будет очень сильно отложено и проверка сразу после вызова будет намного выгоднее и с т.з. производительности и с т.з. диагностики.

D>Кстати, да, что будет быстрее:
D>1)две проверки и явное создание объекта с заданием ему в виде нового объекта строки описания, почему аргумент некорректный
D>2)Автоматическая генерация исключения виртуальной машиной при первой попытке обратиться к непроинициализированному объекту
Зависит от реализации виртуальной машины. Проверка может быть и одна. Время создания исключения не факт что будет отличаться. В любом случае, говорить о производительности в момент возникновения исключительной ситуации такого рода — это вообще абсурд. Это ещё надо умудриться придумать ситуацию, в которой выбор одной из этих двух реализаций будет критичен. Не занимайтесь ерундой.

D>И не надо передергивать.
D>В случае написания метода, который не должен работать в ядре атомной станции, я считаю, что такая очевидная вещь, как проверка на null объектов, к которым гарантировано будет обращение в этом методе из одной строки, должна быть на совести вызывающего. К тому же ваша "проверка" в данном случае ничего не даст, кроме другого типа исключения, которое, как вам и еще некоторым разработчикам кажется, более подходит для данного случая.
Какой ещё "метод из одной строки"? Какой "данный случай"? Мы обсуждаем общую практику программирования, не надо всё так буквально воспринимать (тем более, что автор исходного сообщения специально написал, что упростил код). По-моему именно вы и занимаетесь передергиванием.

D>>>И мне сложно представить разработчика, который при передаче null'овского объекта в подобный метод действительно ожидает увидеть IAE, а не NPE.
B>>См.число голосов за IAE на StackOverflow. Таких разработчиков большинство и они разумны.
D>Предпочитаю прислушиваться к создателям языка и учитывать то, что принято в JDK (хотя и с исключениями) и не пытаться ломать мозг разработчика, переключением с одного формата сообщения о null объекте на другой. Посмотрите на ядро и Collections API, которые используются каждый день.
Интересно, мне сколько раз нужно повторить, чтобы вы поняли, что ситуация может быть классифицирована как некорректный аргумент и лучше всего описывается именно так? Это тривиальное утверждение вам ломает мозг?

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

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

B>>>В мире Java это соглашение является стандартом, которому следуют практически все. С NPE это просто не так — готов поспорить, что многие об этом даже не думают, а пишут, как придётся.
D>>Процент поменьше, но как ни банально это звучит, в случае незапланированного появления null, логичней бросить NPE, чем сидеть и классифицировать исключение по собственной шкале. Что, как я вижу, большинство и делает.
B>Да не логичнее нифига. И не большинство. Я могу хотя бы сослаться на тот же StackOverflow, а у вас вообще какие-то голословные тезисы.

D>>>>И выше же обсуждалось, почему логичнее
B>>>Где именно?
D>>См. посты Блазковича и ссылку в нем.
B>Если речь о ссылке на StackOverflow, то там наиболее популярный ответ обратный.

B>>>Капитан Очевидность подсказывает случай, когда NPE является наиболее подходящим исключением (собственно, для этого и существует):

foo.doSomething(foo.someField); // где foo == null

D>>А может сначала проверить на null и кинуть IllegalStateException? Состояние ведь действительно не располагает к вызову метода или обращению к полю.
B>Это, извините, бред. При чем тут состояние (а главное, чьё?), когда явно нулевой указатель пришел откуда-то?

B>>>А если подумать хоть немного, какой код будет оптимальнее — тот, который сначала поработает, а потом выбросит NPE, или тот, который сразу кинет исключение на некорректный аргумент? Если вы считаете проверку корректности аргумента ненужным усложнением, я не хотел бы столкнуться однажды с вашим кодом.
D>>Оптимальнее тот, который не будет делать ненужных проверок, чтобы кинуть "правильное" с точки зрения конкретного разработчика исключение.
B>Это утверждение неверное и голословное. В общем случае нет точного ответа. Возможна и довольно часто встречается ситуация, когда аргумент используется после выполнения довольно большого числа операций (возможно, вообще не в этом методе — сунули в коллекцию и забыли). Соотв. появление NPE будет очень сильно отложено и проверка сразу после вызова будет намного выгоднее и с т.з. производительности и с т.з. диагностики.

D>>Кстати, да, что будет быстрее:
D>>1)две проверки и явное создание объекта с заданием ему в виде нового объекта строки описания, почему аргумент некорректный
D>>2)Автоматическая генерация исключения виртуальной машиной при первой попытке обратиться к непроинициализированному объекту
B>Зависит от реализации виртуальной машины. Проверка может быть и одна. Время создания исключения не факт что будет отличаться. В любом случае, говорить о производительности в момент возникновения исключительной ситуации такого рода — это вообще абсурд. Это ещё надо умудриться придумать ситуацию, в которой выбор одной из этих двух реализаций будет критичен. Не занимайтесь ерундой.

D>>И не надо передергивать.
D>>В случае написания метода, который не должен работать в ядре атомной станции, я считаю, что такая очевидная вещь, как проверка на null объектов, к которым гарантировано будет обращение в этом методе из одной строки, должна быть на совести вызывающего. К тому же ваша "проверка" в данном случае ничего не даст, кроме другого типа исключения, которое, как вам и еще некоторым разработчикам кажется, более подходит для данного случая.
B>Какой ещё "метод из одной строки"? Какой "данный случай"? Мы обсуждаем общую практику программирования, не надо всё так буквально воспринимать (тем более, что автор исходного сообщения специально написал, что упростил код). По-моему именно вы и занимаетесь передергиванием.

D>>>>И мне сложно представить разработчика, который при передаче null'овского объекта в подобный метод действительно ожидает увидеть IAE, а не NPE.
B>>>См.число голосов за IAE на StackOverflow. Таких разработчиков большинство и они разумны.
D>>Предпочитаю прислушиваться к создателям языка и учитывать то, что принято в JDK (хотя и с исключениями) и не пытаться ломать мозг разработчика, переключением с одного формата сообщения о null объекте на другой. Посмотрите на ядро и Collections API, которые используются каждый день.
B>Интересно, мне сколько раз нужно повторить, чтобы вы поняли, что ситуация может быть классифицирована как некорректный аргумент и лучше всего описывается именно так? Это тривиальное утверждение вам ломает мозг?

Мне кажется NPE более информативен чем IAE.
Вы ловите NPE, смотрите, стек вызовов, все очевидно и ясно. Более того, нет необходимости обрамлять код блоком try/catch.
В случае с IAE нужно некоторое время на анализ, что именно некорректного в параметре метода. Кроме того, допустим вы бы решили выбросить этот ексепшен, проверив параметр на null.
Я думаю, ваше информативное сообщение об ошибке содержало бы, что то типа — "ваш параметр — null", тогда как в NPE сам тип ексепшена говорит об ошибке и проблеме.
Baudolino, возможно вы правы в том, что когда аргумент не используется сразу, а проверка параметра сразу после вызова — выгоднее, тогда даже в этом случае, бросить явно NPE лучше, по причинам, описанным выше.
Baudolino, еще мне кажется вы дискутируете не совсем корректно, я предыдущий пост посмотрел,
сравните:
D>>Оптимальнее тот, который не будет делать ненужных проверок, чтобы кинуть "правильное" с точки зрения конкретного разработчика исключение.
B>Это утверждение неверное и голословное.
Возможно утверждение не верное, но оно точно не голословное, а вот ваша реакция действительно голословна.
Кроме того, вы постоянно используете термины типа "бред", "абсурд", "не занимайтесь ерундой". Научитесь немного уважению к оппоненту, даже если он говорит то, что вам кажется абсолютным бредом. В мире нет абсолютной истины.

С уважением к вам обоим

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

D>>Процент поменьше, но как ни банально это звучит, в случае незапланированного появления null, логичней бросить NPE, чем сидеть и классифицировать исключение по собственной шкале. Что, как я вижу, большинство и делает.
B>Да не логичнее нифига. И не большинство. Я могу хотя бы сослаться на тот же StackOverflow, а у вас вообще какие-то голословные тезисы.

Просьба наконец-то взглянуть на документацию по ядру JDK и Collections API специально проигнорировали, чтобы отвечать не мешало?

B>Если речь о ссылке на StackOverflow, то там наиболее популярный ответ обратный.

Там же есть и аргументы против.

B>>>Капитан Очевидность подсказывает случай, когда NPE является наиболее подходящим исключением (собственно, для этого и существует): foo.doSomething(foo.someField); // где foo == null
D>>А может сначала проверить на null и кинуть IllegalStateException? Состояние ведь действительно не располагает к вызову метода или обращению к полю.
B>Это, извините, бред. При чем тут состояние (а главное, чьё?), когда явно нулевой указатель пришел откуда-то?

"Пришел откуда-то" — это пять. Пришел Дед Мороз и достал его из мешка. Объекты "откуда-то" не появляются. Он, например, может прийти в качестве аргумента в метод. Может быть создан вручную и т.д., и т.п. Состояние, очевидно, имелось в виду объекта, который содержит данный код. И состояние объекта (на всякий случай уточню, что состояние — это значение всех полей и локальных переменных, содержащихся в объекте или в конкретном исполняемом методе) явно не позволяет выполнить этот код без исключения.

B>Это утверждение неверное и голословное. В общем случае нет точного ответа. Возможна и довольно часто встречается ситуация, когда аргумент используется после выполнения довольно большого числа операций (возможно, вообще не в этом методе — сунули в коллекцию и забыли). Соотв. появление NPE будет очень сильно отложено и проверка сразу после вызова будет намного выгоднее и с т.з. производительности и с т.з. диагностики.

Это НЛП такой, начинать все абзацы с "бред", "голословно" и т.д.? Я привел конкретный пример, указав что там такая проверка ненужна и будет просто захламлять код. Вы же берете общий случай, утверждаете, что я вообще против проверки аргументов, а потом красиво проводите разоблачение этого "моего" утверждения.
Говоря вашими словами, вы бредите, голословите, приписываете мне заведомо выгодные вам слова, которые я не говорил. Газета Московский комсомолец ждет вас в качестве журналиста.

B>Зависит от реализации виртуальной машины. Проверка может быть и одна. Время создания исключения не факт что будет отличаться. В любом случае, говорить о производительности в момент возникновения исключительной ситуации такого рода — это вообще абсурд. Это ещё надо умудриться придумать ситуацию, в которой выбор одной из этих двух реализаций будет критичен. Не занимайтесь ерундой.

Хм. "А если подумать хоть немного, какой код будет оптимальнее — тот, который сначала поработает, а потом выбросит NPE, или тот, который сразу кинет исключение на некорректный аргумент?" — чьи слова на мой конкретный пример метода, состоящего из одной строки? Действительно, перестаньте заниматься ерундой. Или хотя бы будьте последовательны.

B>Какой ещё "метод из одной строки"? Какой "данный случай"? Мы обсуждаем общую практику программирования, не надо всё так буквально воспринимать (тем более, что автор исходного сообщения специально написал, что упростил код). По-моему именно вы и занимаетесь передергиванием.

Нет универсального подхода ко всем вомзожным случаям. Я дал конкретный пример. И мое утверждение, что в данном конкретном и похожим на него примерах проверка аргументов ненужна, так как она вообще ничего не даст. Вы же сразу его спроцировали на "общую практику программирования", выгодно для себя сменив тему на "Посмотрите, он даже не собирается проверять аргументы!"

D>>Предпочитаю прислушиваться к создателям языка и учитывать то, что принято в JDK (хотя и с исключениями) и не пытаться ломать мозг разработчика, переключением с одного формата сообщения о null объекте на другой. Посмотрите на ядро и Collections API, которые используются каждый день.
B>Интересно, мне сколько раз нужно повторить, чтобы вы поняли, что ситуация может быть классифицирована как некорректный аргумент и лучше всего описывается именно так? Это тривиальное утверждение вам ломает мозг?

Не беспокойтесь, мозг в порядке в том числе и потому, что не вижу смысла захламлять его новым осмыслением "как же еще красивее сообщить о null", когда есть практика, принятая в JDK.
Я правильно понимаю, что вы так и не удосужились заглянуть в документацию?

D>Просьба наконец-то взглянуть на документацию по ядру JDK и Collections API специально проигнорировали, чтобы отвечать не мешало?
Не надо меня тыкать в документацию, с которой сами не удосужились ознакомиться. Вот, пожалуйста:
http://download.oracle.com/javase/6/docs/api/java/lang/IllegalArgumentException.html
Цитирую: "Thrown to indicate that a method has been passed an illegal or inappropriate argument."
http://download.oracle.com/javase/6/docs/api/java/lang/NullPointerException.html
Цитирую: "...(список ситуаций, в котором нашего случая нет)...Applications should throw instances of this class to indicate other illegal uses of the null object." В момент проверки параметра речи об его использовании нет. С чего вдруг вы вспомнили про Collections API — непонятно.

B>>Если речь о ссылке на StackOverflow, то там наиболее популярный ответ обратный.
D>Там же есть и аргументы против.
Я уже всё о них сказал.

D>"Пришел откуда-то" — это пять. Пришел Дед Мороз и достал его из мешка. Объекты "откуда-то" не появляются. Он, например, может прийти в качестве аргумента в метод. Может быть создан вручную и т.д., и т.п. Состояние, очевидно, имелось в виду объекта, который содержит данный код. И состояние объекта (на всякий случай уточню, что состояние — это значение всех полей и локальных переменных, содержащихся в объекте или в конкретном исполняемом методе) явно не позволяет выполнить этот код без исключения.
Во-первых, http://download.oracle.com/javase/6/docs/api/java/lang/IllegalStateException.html
Во-вторых, под состоянием объекта обычно подразумевается набор значений только полей. В случае статического метода вообще трудно говорить о каком-то объекте. ISE получается притянуто за уши лишь бы поспорить.

D>Это НЛП такой, начинать все абзацы с "бред", "голословно" и т.д.? Я привел конкретный пример, указав что там такая проверка ненужна и будет просто захламлять код.
Примеры никогда ничего сами по себе не доказывали.

D>Вы же берете общий случай, утверждаете, что я вообще против проверки аргументов, а потом красиво проводите разоблачение этого "моего" утверждения.
Я говорю об общем случае именно потому, что о нем вообще всё это обсуждение.

D>Говоря вашими словами, вы бредите, голословите, приписываете мне заведомо выгодные вам слова, которые я не говорил. Газета Московский комсомолец ждет вас в качестве журналиста.
Я вынужден догадываться, что вы имели в виду, говоря очевидно и т.п.

B>>Какой ещё "метод из одной строки"? Какой "данный случай"? Мы обсуждаем общую практику программирования, не надо всё так буквально воспринимать (тем более, что автор исходного сообщения специально написал, что упростил код). По-моему именно вы и занимаетесь передергиванием.
D>Нет универсального подхода ко всем вомзожным случаям. Я дал конкретный пример.
Хорошо, признаю, в вашем конкретном примере проверка, наверное, лишняя. Но ваш пример в таком случае вообще не релевантен обсуждению. Давайте по существу вопроса.

B>>Интересно, мне сколько раз нужно повторить, чтобы вы поняли, что ситуация может быть классифицирована как некорректный аргумент и лучше всего описывается именно так? Это тривиальное утверждение вам ломает мозг?
D>Не беспокойтесь, мозг в порядке в том числе и потому, что не вижу смысла захламлять его новым осмыслением "как же еще красивее сообщить о null", когда есть практика, принятая в JDK.
Вот вам ваша "практика" в JDK: http://rsdn.ru/forum/java/4026072.1.aspx

Автор: Blazkowicz
Дата: 05.11.10

Я уже не первый раз ссылаюсь на это, а вы упорно игнорируете.

А>Мне кажется NPE более информативен чем IAE. Вы ловите NPE, смотрите, стек вызовов, все очевидно и ясно.
Поскольку вы, видимо, невнимательно читали то, что было сказано выше, скажу ещё раз. Видите ли, информативность — вполне измеримое понятие. От количества информации, которое вы получите из сообщения об ошибке, зависит время на отладку. А время — деньги. Казалось бы, пустяковый вопрос: нужно ли проверять аргументы метода и какое бросить исключение в случае null? А вы загляните в javadoc: http://download.oracle.com/javase/6/docs/api/java/lang/NullPointerException.html
В списке возможных причин — пять пунктов (IAE — один), и он ими не ограничивается. Итак, предположим, у вас есть трейс с NPE и нет исходников. Т.е. вам известны только имя метода (и, возможно, номер строки, который вам ни о чем не говорит). Отладка с байт-кодом на руках не всегда возможна (например, вы обрабатываете плохо документированный поток данных из удаленного источника и раз в неделю он падает из-за пустого поля — такое ловится только по логам). Хорошо, если код ваш и в вашем NPE нормальное сообщение о некорректности аргумента. Вот только так бывает далеко не всегда. И приходится ломать голову над тем, почему на тестах всё ок, а продакшн падает с непонятным NPE — какая именно из причин его вызвала? Самые дурные ошибки, приводящие к срыву сроков и потере денег, часто происходят из-за таких пустяковых вопросов. Далее, представьте себе, что вы вдруг решили обработать ошибки, связанные с некорректным аргументом (трудно представить такую ситуацию, но вдруг):

try {
   callFoo(arg1, arg2, arg3);
} catch (IllegalArgumentException e) {
   handleInvalidArgument(e);
} catch (NullPointerException e) {
   String message = e.getMessage();
   if ("Argument is null".equals(message)) { // надо, потому что может быть и другая причина!
      handleInvalidArgument(e);
   }
}

Уродливо, не правда ли?

Что касается всяких best practices от Sun и непогрешимости разработчиков JDK, то, как уже было показано выше, best practiсe по выбросу NPE не следуют даже в стандартной библиотеке, потому что рационального объяснения тому, почему более сематически корректному IAE нужно предпочитать абстрактное NPE, нет.

A>Более того, нет необходимости обрамлять код блоком try/catch.
Эээ.... Оставлю это на вашей совести. При чем тут try/catch?

А>В случае с IAE нужно некоторое время на анализ, что именно некорректного в параметре метода. Кроме того, допустим вы бы решили выбросить этот ексепшен, проверив параметр на null.
А>Кроме того, вы постоянно используете термины типа "бред", "абсурд", "не занимайтесь ерундой". Научитесь немного уважению к оппоненту, даже если он говорит то, что вам кажется абсолютным бредом. В мире нет абсолютной истины.
Признаю, немного погорячился разок.

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

B>Не надо меня тыкать в документацию, с которой сами не удосужились ознакомиться. Вот, пожалуйста:
B>http://download.oracle.com/javase/6/docs/api/java/lang/IllegalArgumentException.html
B>Цитирую: "Thrown to indicate that a method has been passed an illegal or inappropriate argument."

Правильно.

B>http://download.oracle.com/javase/6/docs/api/java/lang/NullPointerException.html
B>Цитирую: "...(список ситуаций, в котором нашего случая нет)...Applications should throw instances of this class to indicate other illegal uses of the null object." В момент проверки параметра речи об его использовании нет.

Видимо, авторы API не думали, что надо перечислять все возможные случаи, и понадеялись на адекватность разработчиков. Случай при проверке аргумента подходит под "other illegal uses of the null object".

B>Во-вторых, под состоянием объекта обычно подразумевается набор значений только полей. В случае статического метода вообще трудно говорить о каком-то объекте. ISE получается притянуто за уши лишь бы поспорить.

Настолько же притянуто за уши, как и категоричность в генерации IAE при null'овых аргументах. Ни больше и не меньше.

B>С чего вдруг вы вспомнили про Collections API — непонятно.
...
B>Вот вам ваша "практика" в JDK: http://rsdn.ru/forum/java/4026072.1.aspx

Автор: Blazkowicz
Дата: 05.11.10

Я уже не первый раз ссылаюсь на это, а вы упорно игнорируете.

По ссылке один пример, когда используется IAE (кстати, в java и javax пакетах я этот пример не нашел, было б интересно узнать, что за класс). Collections и Core API привожу для того, чтобы вы посмотрели, как там и в каких случаях используются NPE и IAE.

Если взять сферического коня в вакууме и представить ситуацию, когда только-только написаны спецификации на обсуждаемые исключения, но еще нет реализации других классов, тогда я теоретически мог бы предположить, что в случае явной проверки аргументов в методе при значениях null можно кидать IAE.
Но реальность такова:
-ядро и основные API для этих случаев явно используют NPE
-один из основателей платформы явно говорит о том, что надо использовать NPE
Я не вижу ни одной причины, почему сейчас надо что-то менять, тем более что момент не принципиальный, чтобы начинать войну и ломать принятые в основных пакетах соглашения.

Аргумент, что на одном из сообществ проголосовало больше человек — это из разряда "миллионы мух не могут ошибаться". Хотя иногда работает. Но в данном случае по сути один человек не поленился досконально аргументировать свою точку зрения, за что и получил много голосов. Правда при этом он свое видение API и языка выдает за прописную истину, а никто другой в свое время не решился указать на это (если что, речь идет о том, что NPE должен кидать не обязательно рантайм, о чем также явно говорится в доке, и что значение null действительно стоит обособленно, как бы это ни удивляло автора того поста).

D>По ссылке один пример, когда используется IAE (кстати, в java и javax пакетах я этот пример не нашел, было б интересно узнать, что за класс).
Поиском по IllegalArgumentException можно найти и другие примеры. Например, в java.awt.Component. Очень много проверок типа "if not instanceof", фактически включающих проверку на null, в том же io.

D>Если что, речь идет о том, что NPE должен кидать не обязательно рантайм, о чем также явно говорится в доке
Из этого не следует, что нужно всякий раз кидать NPE, когда встречается null. В хороших архитектурах всегда отдаётся предпочтение наиболее информативным и подходящим по смыслу исключениям. Вообще идеально — NullArgumentException extends IllegalArgumentException.

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

R>>>>>ИМХО кидать так исключения бред, и если легаси код написан подобным образом, то понятно почему Жава такая тормозная
R>>>>>

R>>>>>public int getLenght(String s1, String s2){
R>>>>>    if ((s1 == null) || (s2==null)) 
R>>>>>       return -1;
R>>>>>    else 
R>>>>>       return s1.length() + s2.length();
R>>>>>}
R>>>>>

B>>>>Бред это заменять исключения на код возврата. Видать тупые люди эти самые исключения придумали, видать в кодах возврата недостаточно хорошо разобрались.

R>>>не люблю медленный код жрущий много памяти. Опыт создания и оптимизации игр под J2ME на моей стороне

D>>Предлагаешь в точке вызова проверять, а не вернул ли метод -1 вместо того, чтобы перед вызовом проверить оба аргумента на null?
D>>Если уж говорить об оптимизации, то в данном случае надо писать код так, чтобы null'овые значения не появлялись. И оптимизировать надо не все подряд, а только узкие места. И уж точно не надо проецировать практики, используемые в J2ME, на всю яву. Или уж жечь по полной и следовать всем заморочкам JavaCard

D>>Если уж говорить об оптимизации, то в данном случае надо писать код так, чтобы null'овые значения не появлялись.
R>Вот это полностью поддерживаю. Я за безопасный код и эффективный код.

Безопасный? Ну-ну.

int someLenght = ...
...
int someVeryImportantValue = someLenght + getLenght(s1, s2);

угадай сколько может такой баг жить в коде если s1 изредка бывает null...

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

D>>По ссылке один пример, когда используется IAE (кстати, в java и javax пакетах я этот пример не нашел, было б интересно узнать, что за класс).
B>Поиском по IllegalArgumentException можно найти и другие примеры. Например, в java.awt.Component. Очень много проверок типа "if not instanceof", фактически включающих проверку на null, в том же io.

D>>Если что, речь идет о том, что NPE должен кидать не обязательно рантайм, о чем также явно говорится в доке
B>Из этого не следует, что нужно всякий раз кидать NPE, когда встречается null. В хороших архитектурах всегда отдаётся предпочтение наиболее информативным и подходящим по смыслу исключениям. Вообще идеально — NullArgumentException extends IllegalArgumentException.

Вы тут спорите, приводите в качестве за и против примеры из стандартной библиотеки. Причем эти примеры как подверждают, так и опровергают оба подхода.
Хочу выложить мнение автора Thinking in Java. Здесь он также ссылается на архитектора Java SE5:
In his weblog,3 Neal Gafter (one of the lead developers for Java SE5) points out that he was lazy when rewriting the Java libraries, and that we should not do what he did. Neal also points out that he could not fix some of the Java library code without breaking the existing interface. So even if certain idioms appear in the Java library sources, that’s not necessarily the right way to do it. When you look at library code, you cannot assume that it’s an example that you should follow in your own code.

Thinking in Java, p. 500.

А>Вы тут спорите, приводите в качестве за и против примеры из стандартной библиотеки.
примеры из стандартной библиотеки отнюдь не главные "за и против". это от безысходности

A>So even if certain idioms appear in the Java library sources, that’s not necessarily the right way to do it.
спасибо, кэп )

тут другое:
одни за рациональность
— контракт нарушил, получи illegal argument exception ( или наследника)
— если обработка iae единообразна, код клиента проще.
другие за ленивость и частую встречаемость(специально не использую слово стандарт)
— если использую аргумент сразу — сразу npe и кину автоматом (если сразу объект не пользую — так и быть кину npe ручками)
— так уже делают в сотне мест, это ожиданно, и, следовательно, least surprise

имхо, правы разумеется первые и мы обсудив плюсы, минусы несколько лет назад, голосуем кодом за первый

Здравствуйте, Аноним, Вы писали:

А>тут другое:
А>одни за рациональность
А> — контракт нарушил, получи illegal argument exception ( или наследника)
А> — если обработка iae единообразна, код клиента проще.
А>другие за ленивость и частую встречаемость(специально не использую слово стандарт)
А> — если использую аргумент сразу — сразу npe и кину автоматом (если сразу объект не пользую — так и быть кину npe ручками)
А> — так уже делают в сотне мест, это ожиданно, и, следовательно, least surprise

А>имхо, правы разумеется первые и мы обсудив плюсы, минусы несколько лет назад, голосуем кодом за первый
Про ещё один пункт, упомянутый а начала обсуждения, забыли. В случае реализации часто используемого кода, как, например, Collection API, можно выиграть в производительности, выкинув явную проверку.