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

S>Тогда мне кажется, что код от chatGPT более скрупулезно подходит к этому вопросу. Например, вы просто написали:
S>

if (prefixNamespaceUriPairs.length % 2 != 0)

S>без предварительной проверки prefixNamespaceUriPairs на null.

Ну проверять всё на свете это уже особая форма паранойи... В данном случае это varargs метод, который будет конструироваться кодом вида new NamespaceContextImpl("p1", "url1", "p2", "url2") и null при таком использовании туда не попадёт. Если сильно захотеть, тот null передать можно. Но и при этом большой беды не будет, т.к. exception вылетит практически сразу же, так что лишняя проверка может хуже и не сделает, но особо не нужна в данном случае.

> Нет такой проверки и в вашем getPrefixes (хотя может такую проверку делает unmodifiableCollection).

Это уже можно считать багом, спасибо. exception там вылетит, но NullPointerException вместо IllegalArgumentException, как того требует контракт. Проглядел.

vsb>>В целом в Java как языке в этом отношении ничего не поменялось, поэтому и принятые практики не поменялись, я полагаю.

vsb>>Обещают добавить в язык not null типы, как в других языках, но когда это будет и будет ли вообще — неизвестно.

S>Как печально.

Ещё добавлю, что современная IDE обычно поддерживает Nullable/NonNull аннотации на уровне линтера. Поэтому систему типов этими аннотациями таки дополнить можно и в целом большинство очевидных багов это устранит, если не игнорировать предупреждения. Это уже безопасность наподобие TypeScript, когда в рантайме проверок нет, но на этапе сборки — есть. Возможно этот подход будет для многих оптимальным, на мой взгляд он похож на правило 80/20 — минимальными усилиями убираются большинство багов. А испещрять код всевозможными ручными проверками — у этого уже есть своя когнитивная нагрузка, и не факт, что польза от поимки редчайшего бага превысит вред от повышения избыточности логики.

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

S>Тогда мне кажется, что код от chatGPT более скрупулезно подходит к этому вопросу. Например, вы просто написали:
S>

if (prefixNamespaceUriPairs.length % 2 != 0)

S>без предварительной проверки prefixNamespaceUriPairs на null.

Ну проверять всё на свете это уже особая форма паранойи... В данном случае это varargs метод, который будет конструироваться кодом вида new NamespaceContextImpl("p1", "url1", "p2", "url2") и null при таком использовании туда не попадёт. Если сильно захотеть, тот null передать можно. Но и при этом большой беды не будет, т.к. exception вылетит практически сразу же, так что лишняя проверка может хуже и не сделает, но особо не нужна в данном случае.

> Нет такой проверки и в вашем getPrefixes (хотя может такую проверку делает unmodifiableCollection).

Это уже можно считать багом, спасибо. exception там вылетит, но NullPointerException вместо IllegalArgumentException, как того требует контракт. Проглядел.

vsb>>В целом в Java как языке в этом отношении ничего не поменялось, поэтому и принятые практики не поменялись, я полагаю.

vsb>>Обещают добавить в язык not null типы, как в других языках, но когда это будет и будет ли вообще — неизвестно.

S>Как печально.

Ещё добавлю, что современная IDE обычно поддерживает Nullable/NonNull аннотации на уровне линтера. Поэтому систему типов этими аннотациями таки дополнить можно и в целом большинство очевидных багов это устранит, если не игнорировать предупреждения. Это уже безопасность наподобие TypeScript, когда в рантайме проверок нет, но на этапе сборки — есть. Возможно этот подход будет для многих оптимальным, на мой взгляд он похож на правило 80/20 — минимальными усилиями убираются большинство багов. А испещрять код всевозможными ручными проверками — у этого уже есть своя когнитивная нагрузка, и не факт, что польза от поимки редчайшего бага превысит вред от повышения избыточности кода.