Re[5]: Проверяют ли в Java аргументы метода на null? - Java

Здравствуйте, 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>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'овые значения не появлялись.
Вот это полностью поддерживаю. Я за безопасный код и эффективный код.

	От:	Blazkowicz
	Дата:	05.11.10 12:44
	Оценка:

	От:	Baudolino
	Дата:	05.11.10 12:45
	Оценка:

	От:	Blazkowicz
	Дата:	05.11.10 12:46
	Оценка:

	От:	Baudolino
	Дата:	05.11.10 12:50
	Оценка:

	От:	vsb
	Дата:	05.11.10 13:16
	Оценка:

От:	Donz	http://donz-ru.livejournal.com
Дата:	08.11.10 09:10
Оценка:

	От:	DimaR
	Дата:	06.11.10 17:31
	Оценка:	-1

	От:	rov63rus
	Дата:	07.11.10 13:10
	Оценка:	-3